Differences between revisions 32 and 33
Revision 32 as of 2006-11-05 23:40:15
Size: 14695
Editor: KevinMcCarty
Comment: Update to reflect new upload of ROOT to NEW
Revision 33 as of 2006-11-06 00:01:08
Size: 5898
Editor: KevinMcCarty
Comment: mention ROOT versions re: Debian suite, and archive old obsolete material
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
Obsolete text on this page has been archived at ["DebianScienceROOT/Obsolete"].
Line 8: Line 10:
   * Packages uploaded to [http://ftp-master.debian.org/new.html NEW] queue on April 27, 2006, by KevinMcCarty and ChristianHolm. These are targeted for "experimental".    * Packages uploaded to [http://ftp-master.debian.org/new.html NEW] queue on April 27, 2006, by KevinMcCarty and ChristianHolm. These were targeted for "experimental".
Line 11: Line 13:
   * To use the experimental archive, add    * The intent is to upload ROOT "development" versions '''5.''odd''.''xx'' ''' only to "experimental", and ROOT "production" versions '''5.''even''.00''' to "unstable", allowing the production versions to propagate into testing and stable over time.
   * Unfortunately the next production release of ROOT, '''5.14.00''', is not expected until post-Etch, but we intend to upload ROOT 5.14 to [http://backports.org backports.org] for Etch users once it is in unstable.
   * To use the experimental archive, add the following to your "/etc/apt/sources.list", where "NN" is your favorite mirror (say, us, no, fi, jp, or dk), and run "apt-get update":
{{{
        deb ftp://ftp.NN.debian.org/debian/ ../project/experimental main
}}}
Line 13: Line 20:
        deb ftp://ftp.NN.debian.org/debian/ ../project/experimental main

    where "NN" is your favorite mirror (say, us, no, fi, jp, or dk) to your "/etc/apt/sources.list", and run "apt-get update".
Line 38: Line 42:
=== 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 use 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.

""Update to the above"": Indeed the upstream sources has been patched to be able to use [http://packages.debian.org/unstable/x11/ttf-freefont FreeFont] instead of the M$ Core Fonts. Also, a GPL'ed Postscript font was found to be able to substitute the M$ Core Fonts "symbol.ttf". This was converted to a TTF (using http://packages.debian.org/unstable/x11/fontforge FontForge]) and submitted upstream. Hence, there are now free alternatives to all fonts for ROOT.
Line 53: Line 51:
== Obsolete ==

=== Repos, etc. ===

 * 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].
 * [http://lists.debian.org/debian-science/2005/08/msg00093.html Ricardo Yanez work] (on stable release - ROOT version 4.04)
   * Would be [http://lists.debian.org/debian-science/2005/08/msg00100.html root for stable Debian distribution]
   * [http://root.cern.ch/root/roottalk/roottalk05/1772.html His repositories]
 * [http://lists.debian.org/debian-science/2005/08/msg00094.html Christian Holm Christensen work] (on development tree - ROOT version 5.08)
 * [http://mirror.phy.bnl.gov/debian-root/ His repository]. See also [http://lists.debian.org/debian-science/2005/08/msg00132.html this]


=== Differences between Ricardo Yanez and ChristianHolm work. ===
  * Package build infrastructure
   * 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.

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

     Therefore, 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 pristine 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.

      * N.B. In the eventual "official" Debian packages to come, the package maintainer would presumably run these two commands himself before '''dpkg-buildpackage''', and the results of the commands (for instance the debian/ directory) would therefore enter into the diff.gz of the source package. Thus the source package uploaded to Debian would always be buildable with the normal steps of '''dpkg-buildpackage -rfakeroot'''. Question: what happens if an end-user does '''apt-get source root''' and then re-runs the makedebdir script? Does it overwrite the existing debian directory with information about the dependencies installed on the end-user's system? (Seems to me that would be the desired outcome.)

      It is important that the maintainer ensure that he has all the needed "official" build-depends installed on his system when running the makedebdir.sh script, and none of the "unofficial" non-DFSG-free libraries (e.g. Pythia) installed, perhaps by building on a pristine machine or in a pristine chroot. Remember that packages are not allowed to munge debian/control in such a way that their Build-Depends change during the dpkg-buildpackage step!

      As a side note, it is also important to ensure that the debian/changelog file is preserved when moving to new upstream versions; without sufficient caution, it looks like it might accidentally be overwritten in such a case. --KevinMcCarty

  * Plug-ins and extensions

   * Ricardo 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 its headers.

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

   * For extensions (things that the end-user should be able to link against explicitly in her code, as with '''g++ myprogram.cc -L/usr/lib/root -lRooFit'''), the Debian library packaging guidelines must be respected: packages of the extension with different sonames must have different package names and be installable in parallel; the -dev package of the extension contains header files and the development symlink (e.g.) /usr/lib/root/libRooFit.so. For plug-ins, it should be sufficient that they can't be dlopened by the wrong version of ROOT. I think the latter is already OK since ROOT 5.08 will read /etc/root/system.rootrc, find out that its plugins are in /usr/lib/root/5.08/ and therefore not see version 5.06 of libMinuit.so which is in /usr/lib/root/5.06/. --KevinMcCarty

  * 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 some of 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); see above.
   * [http://lists.debian.org/debian-science/2005/08/msg00094.html More stuff on this]
   * [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.
    * 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.

1. ROOT for DebianScience

* DebianScience

  • ?DebianSciencePhysics

Obsolete text on this page has been archived at ["DebianScienceROOT/Obsolete"].

1.1. Debian (unofficial) packages

  • [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325306 ITP] submitted by ChristianHolm.

    • Packages uploaded to [http://ftp-master.debian.org/new.html NEW] queue on April 27, 2006, by KevinMcCarty and ChristianHolm. These were targeted for "experimental".

    • FTPmaster rejected these packages on the grounds of licensing issues. In the mean time, these issues have been worked out with the upstream authors and 3rd party developers.
    • Since then, the debian/copyright file has been greatly expanded, and the copyright holders of the non-free material were contacted and agreed to relicense it under LGPL. New ROOT packages targeted at "experimental" were uploaded to the NEW queue on November 3, 2006.
    • The intent is to upload ROOT "development" versions 5.odd.xx only to "experimental", and ROOT "production" versions 5.even.00 to "unstable", allowing the production versions to propagate into testing and stable over time.

    • Unfortunately the next production release of ROOT, 5.14.00, is not expected until post-Etch, but we intend to upload ROOT 5.14 to [http://backports.org backports.org] for Etch users once it is in unstable.

    • To use the experimental archive, add the following to your "/etc/apt/sources.list", where "NN" is your favorite mirror (say, us, no, fi, jp, or dk), and run "apt-get update":

        deb ftp://ftp.NN.debian.org/debian/ ../project/experimental main

1.1.1. Technical issues for packaging

The approach is that 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 pristine 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.

* N.B. In the eventual "official" Debian packages to come, the package maintainer would presumably run these two commands himself before dpkg-buildpackage, and the results of the commands (for instance the debian/ directory) would therefore enter into the diff.gz of the source package. Thus the source package uploaded to Debian would always be buildable with the normal steps of dpkg-buildpackage -rfakeroot.

Question: what happens if an end-user does apt-get source root and then re-runs the makedebdir script? Does it overwrite the existing debian directory with information about the dependencies installed on the end-user's system? (Seems to me that would be the desired outcome.)

Answer: Yes.

It is important that the maintainer ensure that he has all the needed "official" build-depends installed on his system when running the makedebdir.sh script, and none of the "unofficial" non-DFSG-free libraries (e.g. Pythia) installed, perhaps by building on a pristine machine or in a pristine chroot. That is, use pbuilder :-). Remember that packages are not allowed to munge debian/control in such a way that their Build-Depends change during the dpkg-buildpackage step!

1.2. Licensing

1.3. Thanks