root-system should be single package and outside default paths

[Philipp Klenze]

Hello,
I would like you to ask to reassess the organization of CERNs ROOT 
framework in the Debian package system.

Currently, it is split into around 96 packages and gets installed all 
over the system, e.g. in /usr/bin/, /usr/lib/$ARCH/root5-34, 
/usr/include/root/ and /etc/root.

I humbly suggest that you consider moving it into one package and 
placing it in its own directory, e.g. /usr/lib/root/root5.34/.


My reasoning regarding the package splitting:

(0) Just because you can split a package from upstream into multiple 
interdependent packages, it does not mean that it is a good idea. Take, 
for example, iceweasel. This package contains some 18 interdependent 
shared objects. However, it has not been split into 18 different 
packages, because it is assumed that a user installing iceweasel wants 
the browser as it is, and almost nobody wants just the javascript 
engine, the rendering engine or the desktop icon.

(1) For other packages, it is different. A Gnome user might want to 
install just one particular favorite KDE program without installing 
everything included in that desktop environment. Here, a high 
granularity is sensible, because one can expect quite a few people 
wanting okular without having to install amarok (or the other way round).

(2) In my opinion, ROOT is absolutely in the "iceweasel" category. Let 
us assume the opposite. You write a program using the basic TH1I 
histogram class of ROOT. You look up the documentation of said class [0] 
and notices there is no indication given whatsoever against which 
libraries he will have to link. Finally, you figures out that one needs 
libHist.so and thus ask your admin to install libroot-hist-dev. However, 
your story does not end here because rather sooner than later, you will 
need to use another class, so you have to bug both your library oracle 
and your sysad again.

(3) In reality, things works differently. First, you install ROOT. All 
of it (about half a gigabyte, YMMV). You do not think "hm, 46 Megabytes 
just for libTMVA.so sounds rather large, will I need it?" Generally, 
ROOT is used by universities and the like and for the most part, these 
do not depend on dialup to download software. [1]

(4) When you want to get rid of a particular version of ROOT, with the 
one package solution, it is as easy as apt-get purge root-system. With 
the many package solution, apt-get remove root-system; apt-get 
autoremove; actually did not do the trick for me today, leaving me to 
manually hunt down leftover packages, not to mention /etc/root.

(Addendum:)
(5) IMO, the proof daemon and related facilities, however, should not be 
configured to be automatically started by the main root package. 99% of 
the ROOT users will never need them. Using up a bit of disk space is not 
an issue with most research institutions, but having an unneeded daemon 
written by the "who needs snprintf in cint?" ROOT devs waiting for 
someone to test the quality of its input sanitation most certainly is.

Regarding the distribution of files:

(0) Upstream intends ROOT to be installed in a single directory (with 
lib, include, bin, ... subdirectories). [2]

(1) ROOT is often not used in a vacuum by someone starting with an empty 
file, but people use programs written by others which depend on ROOT. 
Many of these assume that $ROOTSYS is set to the root directory of ROOT 
(no pun intended). With Debian ROOT, this assumption fails badly. In 
some cases, different programs will require different versions of ROOT.

(2) IMO, ROOT does not belong into any default OS path (such as 
/usr/bin, /usr/include or /usr/lib). Default paths are great for mature 
software with stable interfaces which just work. Take libc.so for an 
example. It works, probably without the user even knowing it is there in 
most cases. Should you for some obscure reason need to override the 
system default libc, that can be trivially done.

(3) Contrast ROOT. Few people ever accidentally use ROOT without knowing 
it. There exist different versions which are quite, but not entirely 
compatible. This means the typical ROOT user will have to spend at least 
some thought on the selection of a suitable version.  Learning to 
include the correct thisroot.sh in ones shell before using ROOT is by 
far the easiest part of using it.

(4) It is virtually impossible to use another version of ROOT when a 
version is installed in the default path, e.g. by Debian. You can source 
thisroot.sh from your version of choice all you want, you will still end 
up with a mixture of both versions which will instantly crash when run.

(5) Thus, on any system where root-system is installed, users will have 
one version of ROOT they will have to take as gospel. If they need a 
different version (perhaps ROOT 6) or a $ROOTSYS style version for some 
program, they are out of luck.



When I need to install ROOT on a Debian system, I will try one of the 
following:

a) pick a tarball for another GNU/Linux distribution from upstream, copy 
any missing library dependencies (such as ancient libpng versions of 
centOS) over from said distribution, cross my fingers

or

b) download the source and compile it.

Given that Debian already includes all of the ROOT libraries, this seems 
like a waste of time, but is still more worthwhile than trying to work 
with the Debian version for reasons outlined above.


just my two cents,
    Philipp



[0] https://root.cern.ch/doc/master/classTH1I.html
[1] Of course, your troubles are not over yet: you will still have to 
figure out which libraries to link. But when everything else fails, you 
can now at least use grep and nm to figure that out.
[2] Given ROOTs track record of design decisions (lack of namespaces, 
"interpreted C++" instead of scripting language, global variables for 
anything instead of thread safety, ad-hoc C style string parsing, 
misunderstood inheritance (a two-d histogram is most certainly not a 
one-d histogram), mixing up the data with its visualization, ...), ROOT 
is probably not a great authority regarding what is The Right Way(TM). 
In this case, however, I believe them to be correct.