libRooFit/libMinuit for packaged ROOT

ROOT
1

Hi,

I am using ROOT 5.08/00 on a Debian sarge installation.

When making ROOT via ‘make debian’ to create .deb files, I found that some libraries don’t get installed in /usr/lib/root. In particular, I noticed libMinuit and libRooFit were missing. They appear in /usr/lib/root/5.08. Some libraries have soft links from /usr/lib/root into /usr/lib/root/5.08, but not these two. (There are others, but these two are the ones my applications link against.)

My understanding from Christian is that this is a design choice, having to do with accessing plugins only through specific interfaces. However, this causes a problem when compiling/linking against ROOT using ‘root-config --cflags --glibs’. This command does not return /usr/lib/root/5.08 - not to mention that this path must also then be added to LD_LIBRARY_PATH.

Can someone explain what the Right Way™ to proceed is? Or, what is the appropriate file to change so that the soft links to RooFit and Minuit will be added to the roofit and minuit .deb packages?

Thanks!
Chris

2

Hi Chris et al,

It’s true that some of the root-plugin-plugin are really not plugins, but extensions, and the libraries in those should be treated as developer libraries (that is, there should be a sym-link from /usr/lib/root/version/library.so.version to /usr/lib/root/library.so.. I believe that goes for the packages

[quote]root-plugin-ldap,
root-plugin-mlp,
root-plugin-proof,
root-plugin-quadp,
root-plugin-clarens,
root-plugin-peac,
root-plugin-roofit
[/quote]
The rest of the root-plugin-plugin do contain proper plug-ins, and should not contain the above links. For example root-plugin-minuit contain libMinuit. This library is automatically loaded when one starts fitting data if the proper TEnv value is set in .rootrc. However, libFumili from root-plugin-fumili could also be loaded if so specified in .rootrc. The point here is, that the developer should not use TMinuit or similar directly in their code. Instead they should use the proper virtual interface (e.g., TVirtualFitter), and leave the decision of which concrete implementation to use to the user.

Now, for the extension packages mentioned above. There, there’s no virtual interface, and the developer must link to the concrete implementation directly, mandating the sym-link mentioned above.

However, the Debian Policy dictates, that if one has a shared development library in a software package, one must make two Debian packages: a runtime package with the runtime library (e.g., /usr/lib/root/libRooFit.so.version), and one with the link library (actually sym-link e.g., /usr/lib/root/libRooFit.so.) and headers. For RooFit, that would mean the packages libroot-roofitversion and libroot-roofit-dev.

The way we did the Debian and RPM ROOT packages, this split is a bit clumbersome to do. Therefor, I need to figure out exactly how to do this best. I have a couple of ideas but I haven’t had the time to try them out yet. Any suggestions and constributions are welcome.

Note, I recent updated the Debian-Science wiki page on ROOT on exactly that topic (see
http://wiki.debian.org/DebianScienceROOT). To the Debian users listening, consider joining the debian-science mailing list.

Yours,

Christian