Who's supporting what ... Debian, Ubuntu, and mutual contributions to Debian Med

A basic idea behind the concept of Blends with Debian is to bring people together that happen to be interested in the same software - users and developers alike ... and to help users developing into developers when interested. Packages are commonly community maintained. When there is some issue spotted with a particular package, it is natural to everyone to fix it when the fix is free of side-effects and easier than writing an email to the regular maintainer. Or when one feels nice. Or when one is the maintainer.

To me, this very much summarises what Debian Med's support is about: once informed about an issue you fix it and/or inform the upstream developers about it. Different people are good at different kind of packages and different kind of problems and then: not everyone is interested in every bug, not everyone is having sufficient time available. So, we all complement each other rather nicely. No guarantees for anything, but trust in the individuals and the community to care. In contrast to the understanding of the term support in a commercial environment, we do not need to improve the packages beyond what upstream has developed. But when we do, then those changes are sent to upstream for an inclusion with the next version to profit everyone, i.e. also Windows or MacOS X users. For our scientific packages such a zero delta to upstream principle is particularly important to remain compatible e.g. with the bioinformatics community at large that may use the same version of a particular tool without our contributions.

Can we also support Ubuntu? Quite a few Debian Developers, Debian Maintainers, package curators and upstream developers are particularly happy to contribute to Debian Med because of Ubuntu's large user base. For them, getting the package into Debian is the way to get packages into Ubuntu. For software that is compatible to the Debian Free Software Guidelines software, the transition from Debian to Ubuntu is just smooth. And concerning support, any problems noticed for any of the packages in Debian Med, which are all on the periphery of the distribution, shall be fixed equally (i.e. no more than once) between the distros. The users and developers of those downstream distributions to Debian then help in spotting things earlier. These thoughts and more led to the initiation of Utnubu (ubuntU spelled backwards) and more recently the Debian Exchange projects. In my personal universe, I always felt Debian Med to be a couple of years ahead of that development. After all, we have subversion and git repositories to maintain our packages. And everyone can contribute to those packaging efforts. And we have a series of developers on Ubuntu who are actively contributing to it.

For users of Debian Med who are not working with the very latest version of their distro, like with oldstable (lenny) or stable (squeeze), 10.04 (lucid) or 10.10 (maverick), our packaging has some difficulties to reach them. They just won't see the recent submissions to the archive. What is not much of an issue for the core functionalities of a distribution, for the scientific edge this may be a problem. There are multiple answers to this:

• as a user: force installation (with --force) and hope for compatibility with the libraries or compile packages yourself, which is easy:
  
  • add deb-src of unstable to the sources.list
    
  • say apt-get source --build packagename
    
  • dpkg -i *.deb
    
• as packagers: organise repositories also for older versions of the distributions
  

For Debian and Ubuntu this are the backports. But only few individuals have upload permissions to those separate repositories. For Ubuntu, and currently discussed also for Debian, there are also Personal Package Archives, in short PPA. Everybody, and any group of everybodies, can have such a repository under their own control. The upload to an older release commonly just means to specify that name in debian/changelog and then create a source-only package by adding the flag "-S" to dpkg-buildpackage. This saves the maintainer to invest all the build time and brings package maintenance down to netbooks and mobile phones so one can do it while waiting for/in the bus :)

Still, to render packages available to older distributions remains manual labour. There is no official support for those elderly distros, be they from Debian or from Ubuntu. To help the situation just a bit, and to grant access to Ubuntu users for those packages that were sent to the experimental section of Debian and/or help overcome the limitation during the freeze of release, a few weeks ago a first Debian Med PPA was created. Let's see what this brings over time.

Some more technical description of the upload from Debian to the PPA: Descriptions on how to upload are linked to the launchpad site. Just, the friendly abbreviations don't work for Debian. So one goes the manual way. The launchpad ftp server (if you are using FTP) does not report the current working directory but "OK"s every cd you make. This is somewhat irritating when using a client that changes to the pub directory upon login. The upload will then fail.
One should rather adopt the typical tools to upload like dput or dupload. The destination (at least for Debian users) needs to be specified manually e.g. for dput as follows:
cat >> ~/.dput.cf <<EOPUT
[debianmedppa]
incoming = ~debian-med/ppa/ubuntu/
fqdn = ppa.launchpad.net
login = anonymous
method = ftp
allow_unsigned_uploads = 0
EOPUT
After locally building the source (or complete) package and signing it, this can then be uploaded with dput debianmedppa packagename*.changes. I cannot say that I have already completely understood every little aspect of launchpad, e.g. I get very much confused about how to distinguish Eucalyptus from their euca2ools. And I am very bad at Bazaar (their version control system). But I like what I have understood and hope they soon start to also support versions of Debian for their PPA and an auto-porting across releases. Debian is now planning for a Debian variant of PPAs. It is really high time for this and should possibly even substitute the experimental section IMHO. If they can afford it and are well advised, then they will also support some downstream distros with it and attempt auto-backports. We'll see.