Re: $ROOTSYS issues for ubuntu package

From: Christian Holm Christensen <cholm_at_nbi.dk>
Date: Fri, 12 Feb 2010 01:02:08 +0100


Hi Justin,

On Thu, 2010-02-11 at 13:30 -0500, Brett Viren wrote:
> Justin Findlay <jfindlay_at_gmail.com> writes:
>
> > I've been trying out using the ubuntu package for ROOT and I've found
> > encountered a few problems with it. Unfortunately, the ubuntu package
> > as far as I can tell does not specify how the $ROOTSYS variable should
> > be set. ROOTSYS=/ is the natural choice, but then I get problems like
> > this:

No value of ROOTSYS is `natural' if you think about it :-) It could be `/home/software/physics/cern' for all you care.

> Christian is the expert and should correct me if I'm wrong, but I recall
> that the deb packages use the "--prefix" installation method and does
> not use ROOTSYS. They are mutually exclusive. Instead of
> $ROOTSYS/{bin,lib,include}/ one gets <prefix>/bin and
> <prefix>/{lib,include}/root/.

Brett is exactly right. For the Debian/Ubuntu packages you _must_ not set the ROOTSYS environment variable. The packages are built using the `static installation directories'-method (see README/INSTALL - on-line at http://root.cern.ch/viewvc/trunk/README/INSTALL?view=markup - section 3).

Debian (and by extension - Ubuntu) frowns upon (and with good reason) the need to set special environment variables or special values of environment variable for package installed programs, etc. to work. Debian want applications, etc. to "just work" without the need of additional set-up by the end-user - the burden of that is moved to the package maintainer (i.e., me).

In the spirit of "just work", I've put in some effort to integrate ROOT with the normal desktop of users.

Hence, for the Debian and Ubuntu packages things are located in the normal file-system tree at locations mandated by the File-system Hierarchy Standard (FHS). That means, that user programs live in /usr/bin, libraries in /usr/lib, headers in /usr/include/root, data in /usr/share/root, and system-wide configuration files in /etc/root. This is detailed in the README.Debian file of the packages (see also http://root.cern.ch/viewvc/trunk/build/package/debian/README.Debian).

> I suggest never setting ROOTSYS=/ and then try to do any build related
> things as the "root" user.

There's no need to have special privileges when you build stuff - in fact you should _never_ do that. If you for some reason need to fake root privileges (e.g., building a package) you should use 'fakeroot'.

On Thu, 2010-02-11 at 10:23 -0700, Justin Findlay wrote: I've been trying out using the ubuntu package for ROOT and I've found
> encountered a few problems with it. Unfortunately, the ubuntu package
> as far as I can tell does not specify how the $ROOTSYS variable should
> be set. ROOTSYS=/ is the natural choice, but then I get problems like
> this:
>
> Error in <TPluginManager::FindHandler>: Cannot find plugin handler for
> TVirtualStreamerInfo! Does $ROOTSYS/etc/plugins/TVirtualStreamerInfo
> exist?
>
> TVirtualStreamerInfo does exist, but it is located in
> $ROOTSYS/etc/root/plugins, not $ROOTSYS/etc/plugins. Is this a bug?

No, it is not.
> Should ROOT be willing to check $ROOTSYS/etc/root as well as
> $ROOTSYS/etc, or should I contact the package maintainer

That would be me :-)

> and ask him to move all the contents of /etc/root into /etc?

Imagine how hard it would be to find a configuration file if every single package on your system dumped their configuration files into /etc directly (i.e., no special sub-directory). You'd have thousands of files in a single directory, there would be loads of name conflicts, and you'd never know if the file `magic' was for Apache or some other application.

In fact, I'd argue that ROOT should, in the case of an `environment driven build' try to mimic a normal file-system structure. That is, put programs in $ROOTSYS/bin, libraries in $ROOTSYS/lib, headers in $ROOTSYS/include/root, data in $ROOTSYS/share/root, and configuration files in $ROOTSYS/etc/root. In that way, one could easily install ROOT into say /usr/local. This would make perfect sense for multi-host installs where /usr/local is remotely mounted.

It would be even better if ROOT would change all header includes to read `#include <root/T....>' and put every class in the `ROOT' namespace, but that's probably stretching it a bit :-)

Note, that the script `root-config' will actually tell you where things are.

Yours,

-- 
 ___  |  Christian Holm Christensen 
  |_| |  -------------------------------------------------------------
    | |  Address: Sankt Hansgade 23, 4    Phone:     (+45) 35 35 96 91
     _|           DK-2200 Copenhagen N    Cell:      (+45) 24 61 85 91
    _|            Denmark                 Office:    (+45) 353  25 447
 ____|   Email:   cholm@nbi.dk            Web:    http://cern.ch/cholm
 | |
Received on Fri Feb 12 2010 - 01:02:25 CET

This archive was generated by hypermail 2.2.0 : Fri Feb 12 2010 - 05:50:02 CET