ROOT and Debian
First off ... great initiative.
Second, a disclaimer ... I'm not a Debian Developer, lawyer, or
anything, but I do have a fairly good relationship with the ROOT
Now, I've noticed that there's been a great deal of discussion going on
on this list about ROOT , and how to get it into Debian. I
understand that very well, as ROOT is a great piece of software, and
Debian is a cool OS.
Let me start by summarsing the situation regarding ROOT and Debian, as I
In the ROOT source tree is a number of script, that will set up the
`debian' sub-directory to build a number of Debian packages of ROOT.
The packages are
libroot Numerical data analysis framework - shared runtime libraries
libroot-dev Header files for ROOT
root Meta package to install all ROOT packages
root-bin Numerical data analysis framework - general applications
root-cint ROOT version of the C/C++ interpreter
root-doc Tutorial and test suit for the ROOT system
root-plugin-asimage AfterImage plugin for ROOT
root-plugin-castor CASTOR plugin for ROOT
root-plugin-chirp Chirp plugin for ROOT
root-plugin-clarens Clarens plugin for ROOT
root-plugin-dcache dCache plugin for ROOT
root-plugin-fumili Fumili plugin for ROOT
root-plugin-gl GL plugin for ROOT
root-plugin-hbook Hbook plugin for ROOT
root-plugin-krb5 Kerberos (version 5) plugin for ROOT
root-plugin-ldap Ldap plugin for ROOT
root-plugin-minuit Minuit plugin for ROOT
root-plugin-mlp Multi layer perceptron plugin for ROOT
root-plugin-mysql MySQL client plugin for ROOT
root-plugin-netx NetX plugin for ROOT
root-plugin-oracle Oracle client plugin for ROOT
root-plugin-peac PEAC plugin for ROOT
root-plugin-pgsql PostgreSQL client plugin for ROOT
root-plugin-proof PROOF plugin for ROOT
root-plugin-pythia5 Pythia version 5 plugin for ROOT
root-plugin-pythia6 Pythia version 6 plugin for ROOT
root-plugin-python Python plugin for ROOT
root-plugin-qt Qt plugin for ROOT
root-plugin-quadp QuadP plugin for ROOT
root-plugin-ruby Ruby plugin for ROOT
root-plugin-sapdb SapDB client plugin for ROOT
root-plugin-venus Venus plugin for ROOT
root-plugin-xml XML reader plugin for ROOT
root-proofd Parallel ROOt Facility - distributed, parallel computing
root-rootd ROOT remote file server
root-xrootd Extented ROOT file server
ttf-root True type fonts for ROOT
ttf-root-installer True type fonts for ROOT - installer package
Now, I'm afraid I cannot point you to a apt mirror, as I do not have
enough publicly available disk space.
Note, that on a pristine Debian system, it may not be possible to build
all packages, especially things like `root-plugin-oracle',
`root-plugin-sapdb', and other packages that depend on third-party
In a mail  to this list, Ricardo Yanez, complains that the scripts
does not work, and that it's due to a problem in using the system
libafterimage. However, as Ricardo is well aware of, this problem has
been fixed in ROOT some time ago (as discussed on the ROOT mailing
Ricardo's approach is to hand-write a lot of stuff just for Debian,
while my approach has been to make simple, common files, used by both
Debian and RPM packaging tools, to make sort of `standard ROOT packages'
on all GNU/Linux platforms - something that is very attractive to
Physicist working in many places all over the world, all the time.
And frankly, I think Ricardo's assessment, that `A newbee would scratch
his/hers head just to pass this little hurdle', is a tad overdone. I've
explain the various reasons, for the various errors and features of the
packaging script _adopted_by_ROOT_ to him, both personally, and
One of the reasons for the confusion, is that I do not back-port fixes
to the packaging scripts, nor does ROOT back-port changes in general.
Ricardo have tried to build the _stable_ release of ROOT, in which the
packaging scripts does not work. The reason why they don't work, is
because some changes happened in ROOT that I was not aware of (nor was
told of), that messed up some particular things like the libafterimage
With regards to the module loading, the problem is that CINT (the
underlying C/C++ interpreter) uses `file extensions' to recognise file
types, rather than using file magic. That means, that CINT forces
loadable modules to end in one of `.so', `.dll', `.a', `.shl', or
`.lib'. As long as these modules are just that - modules - there's
actually not such a big problem. The problem comes, because the modules
are sometimes treated as shared _libraries_, installing them in
`/usr/lib/root', instead of something like `/usr/lib/root/plugins'.
I've raised the issue with the main authors of ROOT, but I don't think
they have made any decision just yet.
Of course, ROOT should also accept Libtool libraries (.la), and may do
so soon, if CINT starts to use libltdl, as many things could indicate.
With regards to licensing, I believe that there's something waiting in
the wings. I've had discussions with the main authors, and I think they
are leaning towards the LGPL with some renaming clause. I suggest we
bite our tongue and wait and see.
>From a legal point of view (note my initial disclaimer), I think ROOT
should not go into Debian until the license issue has been fixed
upstream. However, I know what the upstream authors really are
worried about, is someone `stealing' ROOT from underneath their feet.
They do not oppose a DSFG-free license at all. In fact, they have asked
me what I think they should to get accepted into Debian proper.
My biggest concern, regarding ROOT and legal issues, is the fact that
ROOT depends on certain TTF fonts, and these are either in the
msttcorefonts package, or there's no package for them in Debian
(symol.ttf, for example). With some minimal tweaking, ROOT could use
the TTF of freefonts or something like that. However, that's a source
code change, and one would need permission to redistribute that.
I've asked the upstream authors why they do not use the TTF extension in
X. They replied, that since ROOT is supposed to work on many platforms,
some sporting very old version of X, using the TTF extension isn't an
option. However, I think they are working on it.
Kevin, if ROOT changes the license, will you sponsor the packages?
___ | Christian Holm Christensen
|_| | -------------------------------------------------------------
| | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91
_| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91
_| Denmark Office: (+45) 353 25 404
____| Email: firstname.lastname@example.org Web: www.nbi.dk/~cholm