ROOTSYS and linux distribution installation

Some linux distributions (fedora as an example) provide ROOT as a set of packages (root.x86_64, root-reflex.x86_64 ,root-graf-x11.x86_64, …) . These are installed in the usual system location, for example the binaries (root, root-config, …) in /usr/bin, the libraries in /usr/lib64/root/ and so on.

This is different from the normal installation where everything is under $ROOTSYS.

This is a problem because some packages (PoD as an example, but also a lot of non official packages used in the analysis) require the $ROOTSYS directory.

The only workaround I’ve founded is to define a directory (like ~/.ROOTSYS) and create a lot of symlink inside it.

Do you have a better solution? Will you provide an official solution?

Instead of relying upon ROOTSYS, use directly the output of:
root-config --cflags
root-config --libs
(and so on -> simply type “root-config” in order to see available flags).

[quote=“Pepe Le Pew”]Instead of relying upon ROOTSYS, use directly the output of:
root-config --cflags
root-config --libs
(and so on -> simply type “root-config” in order to see available flags).[/quote]

yes, I perfectly agree, but the problem is when I want to use a package that require that environment

Well, you can install ROOT from scratch using for example: [url]Installing ROOT from Source

[quote=“Pepe Le Pew”]Well, you can install ROOT from scratch using for example: [url]Installing ROOT from Source

Sure I can, but this doesn’t resolve the original problem: with the installation using the package system you don’t have a ROOTSYS directory.

Honestly speaking, sooner or later, you will learn by hard that the policy of using the “system-provided” ROOT version is a dead end.
You will learn that you need something like three different versions of ROOT - just because something that works with a particular version is not working with another ones.
The safest approach is to “completely remove” all “system-provided” ROOT related packages and install all needed versions of ROOT from scratch, each version in a different “version specific” ROOTSYS subdirectory (e.g. something like “/opt/ROOT/v5-28-00-patches”, “/opt/ROOT/v5-30-00-patches”, “/opt/ROOT/v5-32-00-patches” and so on).

[quote=“Pepe Le Pew”]Honestly speaking, sooner or later, you will learn by hard that the policy of using the “system-provided” ROOT version is a dead end.
You will learn that you need something like three different versions of ROOT - just because something that works with a particular version is not working with another ones.
The safest approach is to “completely remove” all “system-provided” ROOT related packages and install all needed versions of ROOT from scratch, each version in a different “version specific” ROOTSYS subdirectory (e.g. something like “/opt/ROOT/v5-28-00-patches”, “/opt/ROOT/v5-30-00-patches”, “/opt/ROOT/v5-32-00-patches” and so on).[/quote]

I don’t undestand why. If as you said

this is a serious problem of the ROOT software cycle. Usually if there is some problem it is fixed in the newest patch without regression problem. But this is not related with my problem, my problem is different, please remain in topic. I want to use the system packages and be able to use additional packages that require the ROOTSYS environment.

Hi wiso,

please let us know which packages depend explicitly on $ROOTSYS because they need fixing as they should not rely on ROOTSYS but on root-config, or when in code on the global gRootDir or on include/RConfigure.h.

Cheers, Fons.

[quote=“rdm”]Hi wiso,

please let us know which packages depend explicitly on $ROOTSYS because they need fixing as they should not rely on ROOTSYS but on root-config, or when in code on the global gRootDir or on include/RConfigure.h.

Cheers, Fons.[/quote]

as I said PoD is one package (pod.gsi.de/) but there are a lot of packager (for example in the atlas collaboration) using ROOTSYS instead of root-config, I don’t want to fix all of them, so I’m searching for a workaround

In that case do as Pepe suggest, build your own version from source and you’re ok.

Cheers, Fons.