

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!! PLEASE DON'T ATTEMPT NOT TO USE ANY OF THE PACKAGES IN THIS DIRECTORY !!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


Replacing anything in here will MOST LIKELY make Radium UNSTABLE in (more or less) subtle ways. 
There are VERY good reasons for all of the packages included here.


Here are the reasons for including the packages you find in this directory:

1. Modified versions of upstream. (faust2, fluidsynth, gc/libatomic, libgig, libpd, qhttpserver, QScintilla, and Visualization-Library)
   (Yes, patches have been provided upstream.)
2. Almost no, or no, distributions provide the package (faust2, libpd, qhttpserver, qtstyleplugins, s7, and Visualization-Library).
   (Most of these overlap with the packages in point 1.)
3. Needs to be compiled with custom options. (s7, Visualization-Library)
4. Radium requires a newer version that not all distributions provide. (libxcb/xcb-proto).

In the case of libxcb, linking to older versions of libxcb.so WILL CRASH Radium for many users.
Using an older version of libxcb is probably the most common reason Radium has crashed.
And I know this because I get an email with backtrace every time a user presses the "Send" button in the crash reporter window, which pops up when Radium crashes.
After including libxcb with the program, all crash reports caused by libxcb suddenly disappeared.
But if you know that the system version of libxcb is at least 1.12, the package can probably be safely removed.

In addition, it's generally better that the users of a program use the same versions of 3rd party libraries as the developer(s).
This increases stability, but it is currently not the reason for any of the packages in this directory. However, if Qt, for instance, were less stable,
I wouldn't hesitate to include Qt in this directory to make sure everyone used the same version of Qt. Luckily, though, Qt is very stable.
Same goes for libsamplerate, libsndfile, libjack, etc. etc. But in the future, other packages might be included here just as a general precaution.

Also, it's not unusual for larger software to include custom version of other packages.
In fact, it's very common, and for good reasons, as I've explained a little bit above.
Even packages included in Radium have themselves other packages included (Visualization-Library, JUCE, and probably others).



Regarding negative feedback I have gotten about the content of this directory from package distributors
--------------------------------------------------------------------------------------------------------
First of all, there are several packages included with Radium in other directories than this one (with good reasons for those as well).
But for some reason, people are hung up on the specific packages included in this directory. Could it be because of the
name of the directory and the visibility of it? Perhaps I should hide this directory a little bit so that these angry
people wouldn't see it? Anyway, if you are making a Radium package for a Linux distribution, it shouldn't be too hard
without getting angry. Just do the following:

BUILDTYPE=RELEASE RADIUM_QT_VERSION=5 make packages
BUILDTYPE=RELEASE RADIUM_QT_VERSION=5 ./build_linux.sh -j8
rm -fr /opt/radium
cp -a bin /opt/radium
ln -s /opt/radium/radium /usr/bin/radium

And if "make packages" or "./build_linux.sh" fail, please send me a bug report instead of complaining publicly about the build system of Radium.

There's no rational reason to do anything else (except that I would prefer that you distribute the official binary demo packages instead,
that would really save you a lot of work). There's no reason to try using system versions of things you find deep into the Radium source code
that might resemble something your Linux distribution already provides. It will probably make Radium (more) unstable if you attempt to do so.
And there's no need to try to minimize the size of the package by removing apparently unused files. Computers have big harddrives these
days, and the same goes for the web servers. If your distribution has a rule against including modified versions of already existing
packages within a package (albeit a rule you probably have misunderstood), you should either ignore this rule, or use a different Linux distribution.
To sum up: Don't make life harder than necessary.

