Differences between revisions 22 and 24 (spanning 2 versions)
Revision 22 as of 2005-12-16 17:30:53
Size: 3941
Editor: KevinMcCarty
Comment:
Revision 24 as of 2006-01-09 01:50:29
Size: 8492
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:

Do not miss coming [http://indico.cern.ch/conferenceDisplay.py?confId=a0522 ROOT international workshop].
Line 9: Line 7:
 * ROOT [http://lists.debian.org/debian-science/2005/08/msg00056.html provides a direct way to build deb packages from the sources] but is not in Debian main. See [http://cholm.home.cern.ch/cholm/root/debs/ here for some build instructions]. And [http://www.physi.uni-heidelberg.de/~gbrandt/root/non-free/ here] some unofficial prebuild. See also [http://aamorimsrv.fis.fc.ul.pt/ the PaiPix distribution as a source of ROOT debs]  * ROOT [http://lists.debian.org/debian-science/2005/08/msg00056.html provides a direct way to build deb packages from the sources] but is not in Debian main.
   *
See [http://mirror.phy.bnl.gov/debian-root/ here] for some build instructions and a repository for unstable (i386 and amd64).
   *
Also see [http://www.physi.uni-heidelberg.de/~gbrandt/root/non-free/ here] some unofficial prebuild of version 4.04.
   *
See also [http://aamorimsrv.fis.fc.ul.pt/ the PaiPix distribution as a source of ROOT debs].
Line 13: Line 14:
 * [http://lists.debian.org/debian-science/2005/08/msg00094.html Christian Holm Christensen work] (on development tree - ROOT version 5.03)
   * Would be [http://lists.debian.org/debian-science/2005/08/msg00100.html root-snapshot for unstable only]
   * [http://lists.debian.org/debian-science/2005/08/msg00101.html buildd
point is __very__ attractive to ROOT ]
   * [http://lists.debian.org/debian-science/2005/08/msg00101.html previously
ported ROOT to Debian GNU/Hurd]
 * [http://lists.debian.org/debian-science/2005/08/msg00094.html Christian Holm Christensen work] (on development tree - ROOT version 5.08)
   * [http://lists.debian.org/debian-science/2005/08/msg00101.html buildd] point is __very__ attractive to ROOT
   * [http://lists.debian.org/debian-science/2005/08/msg00101.html previously
] ported ROOT to Debian GNU/Hurd
Line 19: Line 19:
 * Currently there do not appear to be plans for upgrades between the unofficial 4.04 .debs, the unofficial 5.03 .debs, and the eventual official .debs to be supported, so be careful!
Line 21: Line 20:
 * [http://lists.debian.org/debian-science/2005/08/msg00090.html the biggest difficulty is that the ROOT libraries are both shared libs and also modules dynamically loaded by the main executable at runtime.]  * Differences between Ricardo Yanez and ChristianHolm work.
   * Ricardo does a traditional packing.
     That is, he maintains a patch to the ROOT source tree, with static packaging files, including the file lists, control file, and so on. This is attractive in it is completely standard.

     However, it has the down-side, that changes in the ROOT source tree has to be dealt with explicitly.

     Richardo makes separate run-time and development packages for all plug-ins and extensions. That is, the plugin '''mysql''' has packages ''libroot-mysql<version>'' and ''libroot-mysql-dev'', and the extesion '''roofit''' has the packages ''libroot-roofit<version>'' and ''libroot-roofit-dev''.

     For extension packages, this is the right thing to do, because users might actually link explicitly against '''libRooFit'''.

     For plug-ins this approach is questionable. ROOT normally loads these plugins in response to implicit requests by the user. For example, if a user requests a connection to a MySQL database, she does '''TSQLServer*''' ''serv'' = '''TSQLServer::Connect'''(''"mysql://...."''), and ROOT loads the plugin module '''libMySQL''' by it self in the background. Hence, the user needn't know about the library '''libMySQL''' or any of the header files that goes with it. Hence, the packaging stuff, should not include the link library '''libMySQL''' or any of it's headers.
   * Christian does a somewhat non-traditional thing.
     He managed to convince the upstream maintainers of ROOT, that they should include packaging stuff directly in the ROOT source tree. This was done to avoid the hurdle of updating the packaging scripts when ever the ROOT source tree changed.

     Therefor, in Christians approach, the ROOT source tree contains [http://root.cern.ch/viewcvs/build/package/lib/ scripts] and [http://root.cern.ch/viewcvs/build/package/common templates] to deal with packaging in general (that is for Debian and RPM), as well as some [http://root.cern.ch/viewcvs/build/package/debian Debian] and [http://root.cern.ch/viewcvs/build/package/redhat RPM] specific templates.
     
     The debian packaging directory is then build by running the script '''[http://root.cern.ch/viewcvs/build/package/lib/makedebdir.sh makedebdir.sh]''', followed by '''fakeroot debian/rules debian/control'''. The packaging scripts will try to build as many packages as possible on the build host. Note, that that sometimes means that you can get packages that wouldn't be possible on a prestine build system.

     Note, that this scheme does not change the way the packages are built. It merely changes how the debian directory is prepared. After the debian directory is made, the developer can still tweak it to fit the system. Of course, such tweaks should eventually be propegated back to the packaging scripts in ROOT itself, to assure consistency.

     For plug-ins and extensions, Christian makes only one package, e.g. ''root-plugin-mysql'' and ''root-plugin-roofit''. For plug-ins, this is exactly the right thing to do (except that the headers are still distributed) as discussed above. For extensions this is wrong, as discussed above.
   * Merging the two approaches.
     In my (Christian) mind, we'd do best with a single approach. The current situation with two packaging schemes is not satisfactory, and is confusing at best.

     I think we need to find a way to unify the two approaches. In my mind that, that amounts to making the right kind of extension and plug-in packages. That is, a a run-time and a development package for each extension, and only a run-time package for the plug-ins.

     I think the best way to go about it, is to make changes to my approach (not because it's mine, but because it's simpler, and ROOT is willing to support it to some extent), by adding new development packages for the plug-in packages.
 * '''Out-dated:''' [http://lists.debian.org/debian-science/2005/08/msg00090.html the biggest difficulty] is that the ROOT libraries are both shared libs and also modules dynamically loaded by the main executable at runtime. This has been partially solved in the current stable ROOT (version 5.08).
Line 23: Line 49:
   * [http://lists.debian.org/debian-science/2005/08/msg00100.html This prevents smooth upgrades between versions of ROOT] and [http://lists.debian.org/debian-science/2005/08/msg00100.html from installing (e.g.) both "root" and "root-snapshot" packages]
 * [http://lists.debian.org/debian-science/2005/08/msg00094.html ROOT depends on certain TTF fonts, and these are either in the msttcorefonts package, or there's no package for them in Debian]
   * [http://lists.debian.org/debian-science/2005/08/msg00100.html This prevents] smooth upgrades between versions of ROOT and [http://lists.debian.org/debian-science/2005/08/msg00100.html from installing] (e.g.) both "root" and "root-snapshot" packages. This point is largely moot in the face of the new (5.08) production version ROOT, and probably will be in all future.
 * '''(Semi-)Out-dated:''' [http://lists.debian.org/debian-science/2005/08/msg00094.html ROOT depends on certain TTF fonts], and these are either in the msttcorefonts package, or there's no package for them in Debian.
   * ROOT can be patched to user other fonts if needed, at least for most fonts. However, there are no real substitute for the symbol.ttf font used for Greek letters and the like. One could imagine using something like opens.ttf from OpenOffice.org, but it's not quite the same, and it requires major code changes in ROOT. Another way to deal with all this, would be to use the Computer Modern fonts (TeX fonts), which contains all the needed symbols, though scattered over many font files.
Line 26: Line 53:
   * This issue is in the process of being addressed by Christian and upstream.    * This issue is in the process of being addressed by Christian and upstream.   A patch based on some work by Kevin has been submitted to upstream, and will hopefully soon enter into ROOT.
Line 29: Line 56:
 * The LGPL only applies to the current version of ROOT in CVS (version 5.03); prior versions still have the [http://root.cern.ch/viewcvs/LICENSE?rev=1.2&content-type=text/vnd.viewcvs-markup original] non-free license.  * The production version of ROOT (5.08 as of Jan 8, 2005) is LGPL'ed. The LGPL only applies to the current version of ROOT in CVS (version 5.03); prior versions still have the [http://root.cern.ch/viewcvs/LICENSE?rev=1.2&content-type=text/vnd.viewcvs-markup original] non-free license.
Line 31: Line 58:
 * [http://lists.debian.org/debian-science/2005/08/msg00090.html Ricardo Yanez is working on .debs that will be Policy-compliant and suitable to upload into Debian as soon as the licensing situation is fixed.]  * [http://lists.debian.org/debian-science/2005/08/msg00090.html Ricardo Yanez] is working on .debs that will be Policy-compliant and suitable to upload into Debian as soon as the licensing situation is fixed.

ROOT for DebianScience

Thanks to [http://lists.debian.org/debian-science/2005/08/msg00066.html Brad Sawatzky] among others.

1. Debian (unofficial) packages

1.1. Technical problems for packaging

  • Differences between Ricardo Yanez and ChristianHolm work.

    • Ricardo does a traditional packing.
      • That is, he maintains a patch to the ROOT source tree, with static packaging files, including the file lists, control file, and so on. This is attractive in it is completely standard. However, it has the down-side, that changes in the ROOT source tree has to be dealt with explicitly.

        Richardo makes separate run-time and development packages for all plug-ins and extensions. That is, the plugin mysql has packages libroot-mysql<version> and libroot-mysql-dev, and the extesion roofit has the packages libroot-roofit<version> and libroot-roofit-dev.

        For extension packages, this is the right thing to do, because users might actually link explicitly against libRooFit.

        For plug-ins this approach is questionable. ROOT normally loads these plugins in response to implicit requests by the user. For example, if a user requests a connection to a MySQL database, she does TSQLServer* serv = TSQLServer::Connect("mysql://...."), and ROOT loads the plugin module libMySQL by it self in the background. Hence, the user needn't know about the library libMySQL or any of the header files that goes with it. Hence, the packaging stuff, should not include the link library libMySQL or any of it's headers.

    • Christian does a somewhat non-traditional thing.
      • He managed to convince the upstream maintainers of ROOT, that they should include packaging stuff directly in the ROOT source tree. This was done to avoid the hurdle of updating the packaging scripts when ever the ROOT source tree changed.

        Therefor, in Christians approach, the ROOT source tree contains [http://root.cern.ch/viewcvs/build/package/lib/ scripts] and [http://root.cern.ch/viewcvs/build/package/common templates] to deal with packaging in general (that is for Debian and RPM), as well as some [http://root.cern.ch/viewcvs/build/package/debian Debian] and [http://root.cern.ch/viewcvs/build/package/redhat RPM] specific templates.

        The debian packaging directory is then build by running the script [http://root.cern.ch/viewcvs/build/package/lib/makedebdir.sh makedebdir.sh], followed by fakeroot debian/rules debian/control. The packaging scripts will try to build as many packages as possible on the build host. Note, that that sometimes means that you can get packages that wouldn't be possible on a prestine build system. Note, that this scheme does not change the way the packages are built. It merely changes how the debian directory is prepared. After the debian directory is made, the developer can still tweak it to fit the system. Of course, such tweaks should eventually be propegated back to the packaging scripts in ROOT itself, to assure consistency.

        For plug-ins and extensions, Christian makes only one package, e.g. root-plugin-mysql and root-plugin-roofit. For plug-ins, this is exactly the right thing to do (except that the headers are still distributed) as discussed above. For extensions this is wrong, as discussed above.

    • Merging the two approaches.
      • In my (Christian) mind, we'd do best with a single approach. The current situation with two packaging schemes is not satisfactory, and is confusing at best. I think we need to find a way to unify the two approaches. In my mind that, that amounts to making the right kind of extension and plug-in packages. That is, a a run-time and a development package for each extension, and only a run-time package for the plug-ins. I think the best way to go about it, is to make changes to my approach (not because it's mine, but because it's simpler, and ROOT is willing to support it to some extent), by adding new development packages for the plug-in packages.
  • Out-dated: [http://lists.debian.org/debian-science/2005/08/msg00090.html the biggest difficulty] is that the ROOT libraries are both shared libs and also modules dynamically loaded by the main executable at runtime. This has been partially solved in the current stable ROOT (version 5.08).

  • (Semi-)Out-dated: [http://lists.debian.org/debian-science/2005/08/msg00094.html ROOT depends on certain TTF fonts], and these are either in the msttcorefonts package, or there's no package for them in Debian.

    • ROOT can be patched to user other fonts if needed, at least for most fonts. However, there are no real substitute for the symbol.ttf font used for Greek letters and the like. One could imagine using something like opens.ttf from OpenOffice.org, but it's not quite the same, and it requires major code changes in ROOT. Another way to deal with all this, would be to use the Computer Modern fonts (TeX fonts), which contains all the needed symbols, though scattered over many font files.

    • Would be [http://lists.debian.org/debian-science/2005/08/msg00100.html OK for contrib] better to look for main.

    • This issue is in the process of being addressed by Christian and upstream. A patch based on some work by Kevin has been submitted to upstream, and will hopefully soon enter into ROOT.

2. Licensing