Debian – building Debian package with non-standard options

Wanting more recent packages is a common issue on any OS. Debian's release cycle has averaged 2 years in recent years, so towards the end of this cycle, it is perhaps a more pressing issue. One way of mitigating this is to move to testing towards the end of the stable release cycle, when the next version is almost stable. It is not clear from the question whether it is talking about stable on more generally about testing and/or unstable as well. Regardless, having the most recent version can be an issue even if one if running unstable, as the most recent version may not be packaged yet. Debian developers/packagers are volunteers, so they may get bored, or busy with other things, with the result that the package languishes.

For simplicity and concreteness I assume in what follows that the plan is to backport a package to stable, but it applies more generally. So, here is what I do if I want a more recent version of software that is not present in stable, in an approximate order.

1. Look for the package in Debian Backports. Sometimes you can find a package that is recent enough to satisfy your purposes. However, it is often the case that these packages are outdated compared to the version in unstable or experimental or upstream.

2. Try to install the package directly from testing, unstable, or experimental. If stable has not diverged much from whatever version you are trying to install from, this may work. You'll know this approach is a bad one if the system starts trying to install or upgrade basic packages from the more recent version. Suppose you are trying to install from unstable, then

   apt-get install packagename/unstable
   

   is the first thing to try. With versions of apt in stable, this will often fail, as it requires other packages from unstable, and this incantation only ups the preference of packagename sufficiently high for it to be installed in unstable. If you don't understand what this means, go away and read man apt_preferences. Carry on adding dependencies from unstable, making sure that it is not trying to upgrade basic packages. For example, if it starts trying to upgrade libc6 or X or KDE or Gnome, abort immediately. It is usually fine if it is tries to upgrade other packages from the same source package, as these are usually tightly coupled together. To see what source package a binary package depends on, do

   apt-cache showsrc packagename
   

   Since lots of stuff depends on the GNU C library (libc6) this used to be a problem. More recently, the API seems to have stabilized, so it is now more often possible to get away with not having to upgrade it. If a package satisfies its runtime dependencies on stable, but still does not work correctly, file a bug. If the packager tells you it is not a bug, they are wrong. :-)

3. Backport the package yourself from testing, unstable or experimental.

   As mentioned above, backports is one option, but often these packages are outdated compared to the version in unstable or experimental or upstream.

   This can often require a recursive dependency build loop type thing. You first need to get the build dependencies with

   apt-get build-dep packagename    
   

   If this fails because one of the dependencies is not recent enough, you'll need to backport that dependency first. This can spriral out of control. I usually give up if I have to deal with more than 2 levels of recursion. Note however, that the real dependencies aren't necessarily as tight as stated ie. an older version may work. The packager often don't try to find the oldest version of a build (or, indeed, runtime) dependency that will work.

4. Check for the availability of packages from the corresponding upstream. Ideally these would match your distribution version, but you might also be able to rebuild them if necessary.

5. Create packages for version of the software more recent than the most recent packages in testing/unstable/experimental. This can be relatively challenging, but still sometimes surprisingly doable. The first thing to note is that if you are trying to package a more recent version of a package that is already in Debian, you are already starting with a big advantage, namely that you have the existing packaging to work with. Just do

   apt-get source packagename
   

   and apt-get will download the corresponding source package, including the debian subdirectory where the packaging lives. Note furthermore that these days, this packaging often lives inside some verson control repository (git seems popular with Debian) and stable apt (currently 0.8.10.3) helpfully tells you where this is when you invoke apt-get source. You should look at this, because the packagers may have more recent versions of the packaging than corresponds to any released package. Eg.

   $ apt-get source mercurial
     Reading package lists... Done
     Building dependency tree       
     Reading state information... Done
     NOTICE: 'mercurial' packaging is maintained in the 'Svn' version control system at:
     svn://svn.debian.org/python-apps/packages/mercurial/trunk
   

   Alternatively, you could simply use

   apt-cache showsrc mercurial | grep Vcs
   

   to list the repository.

   If the package is badly out of date, you may have to make modifications to the
   package, refresh the applied patches but it is still usually a good starting
   point. Debian seems to be in the process of standardizing package management on
   quilt per the dpkg-source 3.0 (quilt) format, so that helps with patch refreshing.

   I'll conclude with a real-life example of how I backported the Debian package of pgf. The last packaged version of pgf was 2.00 in 2008, and since then 2.10 had been released. See the discussion in Please update to newest stable version of pgf (2.10), and my followup bug with a patch, pgf: patches against 2.0 Debian packaging. As it turns out, the Debian packaging of pgf was very simple, and I just had to change one line in the 2.10 packaging to make it work. I ended up quelling all the lintian complaints as well, but that was strictly optional.

If this is true, what is so special about dpkg that is not available with the other commands?

The other commands are not a package manager replacement, that's what makes dpkg so special. You can really extract the contents of all the package and drop it in your root directory, but that doesn't mean they will be working properly. You have no way of tracking dependencies, identify what package installed what files, post/pre installation and removal scripts, and many other nifty features that package managers provide.

What they meant with that paragraph, is, that in case you mess up big time, you can download the files, extract them and recover your system, as makeshift replacement for the proper tool:

This seemingly trivial property is important for portability and disaster recovery

So, the importance of DPKG is great, but they have put failsafes in place so that in case of disaster, you can recover fairly quickly.