Re: ROOT and Debian
Hi Christian,
On 8/13/05, Christian Holm Christensen <cholm@nbi.dk> wrote:
> In a mail [2] 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
> list).
[snip]
> 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
> issue.
Fair enough. But I suspect that most Debian users who use ROOT would
prefer that the current stable version (4.04, right?) be packaged, so
this is the base we're starting from.
You've just pointed out that the packaging scripts do have some
problems in version 4.04, so what Ricardo has been doing makes sense
to me.
Of course this doesn't rule out the possibility of also having
"root-snapshot" packages that follow bleeding-edge CVS. There are a
lot of precedents for this in Debian; see the "emacs-snapshot" and
"gcc-snapshot" packages for instance. In general, though, the
"*-snapshot" packages only exist in Sid and won't make it into stable
Debian releases, where they would quickly grow stale and
unsupportable.
> 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.
ACK. Thank you for bringing up the issue with upstream.
At risk of belaboring the point, and for the benefit of other
debian-science readers, the problems with ROOT dlopening "libfoo.so"
with no soversion are as follows: it prevents a user from installing
(e.g.) both "root" and "root-snapshot" packages, or even from
installing the Debian packages plus a locally compiled version. In
the first case the packages are not simultaneously installable because
both sets of library packages must install a libfoo.so symlink. This
will also prevent smooth upgrades between versions of ROOT with
different sonames, because the old library packages won't be able to
hang around on a user's system until other packages depending on them
are recompiled. (And yes, there exists at least one Debian package
[mn-fit] which will have a ROOT dependency added as soon as ROOT can
go in main.) In the second case, the root executable from the Debian
packages may try to dlopen a module in /usr/local (or vice versa)
which has a different major version and therefore a different ABI.
Why does CINT force loadable modules to have a specific naming
convention? Is there any reason I shouldn't be able to tell it to
load "my_stupidly_named_file.foo" if I know that the file contains
valid object code?
> >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.
It seems that even getting ROOT accepted into non-free would require a
huge amount of work (required to fix license conflicts with Cernlib
and XClass), so I'm inclined to agree for now. This opinion could
change if another year passes and there has still been no action on
the license problems.
By the way, to answer a point you raised in this email on root-talk:
http://root.cern.ch/root/roottalk/roottalk05/1772.html
> The exact license of Minuit (not CERNLIB - but Minuit)
> is actually very restrictive (see
> http://wwwasdoc.web.cern.ch/wwwasdoc/minuit/node1.html).
> I'm not sure how Kevin worked around that one.
My understanding is that since CERN has sole copyright over Minuit (as
stated on the page you cite), Minuit, as part of Cernlib, is included
in the relicensing of Cernlib to GPL stated here:
http://cernlib.web.cern.ch/cernlib/conditions.html If you think this
is incorrect, please say so and I can email Ian McLaren to ask for a
clarification.
> 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.
Not once the license is fixed :-) Alternatively, it should be OK for
ROOT to depend upon msttcorefonts if the root packages are placed in
contrib or non-free (depending upon the ROOT licensing status). I'm
pretty sure that use of fonts doesn't qualify as "linking" so it
should be legit for a Free Software program to use Microsoft fonts.
However I'd really prefer to see the TTF code added so ROOT could go
into main -- it has a lot of advantages over contrib, such as
automatic buildd compilation.
> Kevin, if ROOT changes the license, will you sponsor the packages?
I am still waiting in the NM queue so I can't sponsor anything (yet).
I'm sure a current DD will be happy to upload the packages once they
are finished and legally clear.
That brings up the matter of whose packages get uploaded. :-) I
really suggest that you and Ricardo work together on the packaging,
especially since he already has a place to host the .debs. If the
license is fixed soon, probably the 4.04 packages will go into Debian
first. So it would be nice if you two can ensure that upgrades from
the 4.04 packages to the ones in ROOT CVS are smooth. Don't forget
about soname issues! As always, I'll be happy to look over the
packaging work in my spare time, but can't contribute substantially
until my thesis is done (another month or two).
best regards,
--
Kevin B. McCarty <kmccarty@princeton.edu> Physics Department
WWW: http://www.princeton.edu/~kmccarty/ Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
Reply to: