How To Get Debian Med Packages (aka. the user FAQ)

The main emphasis of the Debian Med web pages hosted on this site is to provide information for developers and packagers. If you are a user of Debian or Ubuntu and just want to make use of Debian Med packages then this page is for you.

Q. How do I find out what packages Debian-Med has available?

A. See the tasks page. This lists the existing packages, as well as work in progress and software that has been considered by Debian Med but not packaged for various reasons. Note that Debian Med does not have a monopoly on packaging biomedical software, and some tools are borderline as to the category they fit in and are in fact maintained by other individuals or teams, for example Debichem or Debian Science. To be sure, look up the package on qa.debian.org to see who is working on it.

Q. I can see package X listed on Debian Med. How do I install it?

A. apt-get install package-x Because Debian Med is a Debian Pure Blend it is generally expected that users will get the packages we make as part of the normal Debian distribution. Packages will be pushed to Sid as soon as possible when they are ready, and should then be automatically added to Testing around ten days later. New packages will not be pushed to Debian Stable until a new stable release is made.

Q. Can I just install Debian-Med in one go?

Yes. apt-get install med-bio

Q. What about Ubuntu?

A. Despite the name, this project is not exclusively about producing packages for Debian, and many packagers are involved with both Debian and Ubuntu. Debian Med packages automatically become part of Ubuntu, but this process takes time so the Ubuntu package will often be behind the one you see in Debian Sid. As with Debian, new packages and non-critical updates are not added to an Ubuntu release after the release freeze (a month or so before the release date). And packages in the experimental section of Debian may not be acceptable for the Ubuntu main distributions.

The process for getting the packages into Ubuntu is the responsibility of the Ubuntu MOTO developers and follows a set procedure aided by the Merge-o-Matic system system. Critical updates applied to already-stable releases are added separately in Debian and Ubuntu by the relevant local maintainers, but these are fairly rare among the packages maintained by Debian Med.

To help the situation with Ubuntu packages being out-of-date, Debian Med uses a Personal Package Archive on Launchpad. This allows any Debian Med developer to backport packages to any release of Ubuntu, making use of the Launchpad build system. But this is not automated and is not a priority for most packagers. You may need to ask for a specific package on the mailing list.

Q. What about other Linux distros?

A. Due to fundamental technical differences between DEB packages and formats like RPM or Gentoo Ebuilds, the packaging work done by Debian Med does not translate easily to ?RedHat, Suse, CentOS, Scientific Linux, etc. Therefore our efforts are not likely to be useful to users of these systems. An exception is Linux Mint which takes the ?http://community.linuxmint.com/software/search directly from Ubuntu and therefore has all the same Debian Med software as the regular Ubuntu distribution. You can also add our PPA to a Linux Mint system [I need to check this is true - Tim].

Q. I want a package that isn't in the Debian Archive, or a newer version of one that is. What can I do?

A. Supporting backports (newer packages to work on an older Debian or Ubuntu base) is something we do not currently do, but we recognise that this is a common need, especially given the rate of development of many scientific applications and the understandable tendency of departments to run a Stable OS platform (either Debian Stable or Ubuntu LTS) as opposed to Debian Testing. There are various ways you might try to get newer packages on your system. These are not without their problems, and in many cases will be no easier than compiling from source, but may be useful for many people.

  1. Install packages from the NEBC Bio-Linux project. Bio-Linux is a customised Ubuntu distribution produced by the NERC Environmental Bioinformatics Centre in the UK. Some of these packages are backported from Debian while others are manually compiled or prepared from pre-compiled downloads. Bio-Linux aims to have the most popular packages no more than a month out of date.

  2. Try installing packages from the newer Debian or Ubuntu release directly. If the package installs cleanly then in theory it should work. Packages can be downloaded from packages.debian.org or packages.ubuntu.com respectively. The downside is that some packages will not install cleanly due to missing dependency requirements, and even if the package installs you will miss out on automatic updates.

  3. For Ubuntu users, try our Launchpad PPA as mentioned above. You can also search Launchpad for packages of interest but be aware; they have no way to audit what gets uploaded on the site and so you should consider carefully before installing software from a PPA.

  4. Try doing the backport yourself, by building a source package into a binary DEB. See the next question.

Q. I'm running Debian Testing. How long do I have to wait for package X to be updated?

A. If you use Debian Testing you should bookmark the fantastic 'Why is package X not in testing yet?' page to see how your package is progressing. This can report on any package in Debian.

Q. As a user, can I download anything directly from Debian Med?

A. As stated above, Debian Med does not directly distribute any ready-to-run software, because Debian/Ubuntu/etc. are the distribution mechanisms. We make what are referred to as source packages, but these are in fact the instructions needed to automatically build the upstream source of an application into the DEB packages which you can install on your computer. We share these via SCM repositories like Subversion or Git (different developers prefer different SCM systems) and you can access these if you want to try building a DEB for yourself. All packaging work (not limited to Debian Med) can be browsed through the portal at http://anonscm.debian.org.

Q. What's the easiest way to build a Debian Med package from source myself?

A. If you are familiar with building applications from source (configure ; make ; make check ; sudo make install) then building .deb packages is fairly similar. In theory, the packages should all build by a standard process, but as code and dependencies change you may need to do some tweaking to make the build work. There is plenty of information on-line but by way of illustration here is a recipe to build Velvet 1.1.05 and make a .deb package on a fresh Ubuntu 11.04 box.

   1  #Install essential tools
   2  sudo apt-get install subversion devscripts quilt
   3 
   4  #Make a work area
   5  mkdir -p velvet-build/latest
   6  cd velvet-build/latest
   7 
   8  #Fetch build metadata from SVN and pull original tarball from upstream site using uscan,
   9  #then unpack it.
  10  svn co svn://svn.debian.org/svn/debian-med/trunk/packages/velvet/trunk/debian
  11  uscan
  12  tar --strip-components=1 -xvzf ../*.orig.tar.gz
  13 
  14  #Check the version of the tarball you downloaded and set the version of this package appropriately.
  15  #In this case I had velvet_1.1.05.tgz
  16  dch -v 1.1.05-custom1 'Local build of new version'
  17 
  18  #See what build dependencies are required and then install them manually
  19  dpkg-checkbuilddeps
  20  sudo apt-get install cdbs debhelper zlib1g-dev help2man
  21  
  22  #Check patches.  Sometimes, a patch fails and needs to be fixed manually.
  23  export QUILT_PATCHES=debian/patches
  24  quilt push -a   #Try to apply all Debian-specific patches.  If this works, skip to next part
  25  quilt push -f   #There is an error, so force the final patch
  26  cat *.rej       #Examine conflicts
  27  nano Makefile   #Manually fix missing -lm -lz in Makefile
  28  quilt refresh   #Commit new version
  29  rm *.rej        #And clean up rejects file
  30 
  31  #Now you can build the whole thing to get your .deb
  32  debuild -i -us -uc -b
  33 
  34  #And it is ready to install
  35  sudo dpkg -i ../velvet_1.1.05-custom1_amd64.deb

The above is the most direct route to building a fairly simple package for your own use, but if you want to get more involved in package building or contribute fixes back to Debian Med then it is suggested to read the available documentation, and especially the Debian Med group policy. This package happens to be in the Subversion repository but the package you want may be in Git, and also note that some tools may be part of a larger download and will be packaged under that name. The trickiest bit in the above build was that the final patch failed because the small issue it addressed had been fixed by the newer upstream but in a slightly different way. Sorting this out it required a little knowledge of the quilt patch system, Makefile syntax, and linking to standard shared libraries (libz, libm) in order to get a working Makefile. Quilt was then refreshed to capture the necessary modifications as a patch file. The aim is to get to the point where 'debuild' runs successfully as this does all the work to build the source and make the DEB, and will complain if there are outstanding dependency or patch issues.

If you attempt a package build and get compilation failures, even when all dependencies are satisfied, then people on the Debian Med mailing list should be able to help.

Q. I succeeded in making a package compile; how do I contribute my build for others to use?

A. Debian Med does not directly distribute binary packages, so if you wanted to share the binary .deb you would have to do so yourself. If you are an Ubuntu user the PPA facility on Launchpad may be what you are looking for.

If you have fixed an error with a package, for example to make it compatible with a new version of the upstream release, then the package maintainer will appreciate your help. In the example above I tested building a newer version of Velvet and fixed one of the patch files to work with this new version. I can generate a patch file that captures my updates like so:

   1 ( cd debian && svn diff ) > /tmp/my_changes_to_velvet.patch

Now I can contact the maintainer of the package (as listed in the debian/control file or revealed by dpkg -s etc.) directly, copying the message to the mailing list. If I explain my changes clearly the maintainer will see that they are correct and a push the changes through to Debian. These can go into Debian Sid immediately filter through to Debian Testing and the Ubuntu development release in short order.