Please prefix generic library names with ROOT

[stephanlachnit]

Explain what you would like to see improved

I'm currently working on getting ROOT into the official Debian repositories for easy installation. However, a major hassle is the name of the shared libraries: these include very generic names like for example libCore.so, libGui.so, etc. The conflict here is that Debian usually splits shared libraries in separate packages with their library name. However a package with e.g. the name libcore is just not explicit enough. A better and much more precise name would be libROOTCore.so.

Optional: share how it could be improved

I see two possible ways to achieve this: one would be to simply add a prefix to all libraries globally, the other would be to rename the libraries in CMake itself. The latter one is probably a time-consuming task, and also needs to handle cases like e.g. libHist, since both libHist and libROOTHist exist. The prior one could be easily added with a CMake option, or just done automatically when building with gnuinstall=ON.

[Axel-Naumann]

Thanks for contacting us! The main issue is backwards compatibility - all those Makefiles that just link against -lCore. But you're providing excellent motivation to find a solution :-)

Having ROOT libraries in <libdir>/ROOT/ isn't an option for Debian?

[eguiraud]

(just as a note of color: we completely agree about which naming convention is better, and in fact newer ROOT libraries follow the convention you propose, but libraries that have been there since 25+ years still have names without "namespacing" -- for backward comp. as Axel says. unfortunately those libraries are the ones with the most generic names!)

[stephanlachnit]

Having ROOT libraries in /ROOT/ isn't an option for Debian?

This is what I currently do for my private builds, but this requires changing the linker's search path, which isn't allowed in official Debian packages as it breaks Debian's tools to automatically detect dependencies (the policy specifies that libraries in <libdir>/<something>/ are private libraries (e.g. plugins), so dependency checking is turned off on purpose).

The main issue is backwards compatibility - all those Makefiles that just link against -lCore.

Right, maintaining backwards compatibility is probably a necessity for such a change. Maybe one can add a (by default enabled) option to symlink from the old libraries to the new ones? I.e. libCore.so -> libROOTCore.so? For the average ROOT user this won't make any difference, and in Debian we can disable the option (I don't expect anyone running ROOT software that is still written with Makefiles instead of CMake using Debian system packages).

This could be achieved in CMake by adding a new option to the ROOT_STANDARD_LIBRARY_PACKAGE marco, looking something like:

ROOT_STANDARD_LIBRARY_PACKAGE(ROOTGui
  HEADERS
    ...
  SOURCES
    ...
  DICTIONARY_OPTIONS
    ...
  DEPENDENCIES
    ...
  BACKWARDS_COMPAT
    Gui

[Axel-Naumann]

Yes, that should work! We will need to figure out new names that don't clash (you mentioned libROOTHist).

[bellenot]

And for which platforms should we do this? (we cannot create symlinks on Windows)

[Axel-Naumann]

What about we do this for gnuinstall as proposed by @stephanlachnit and error out if gnuinstall is passed on Windows?

[bellenot]

OK