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
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.