Most of the "Software" I install on my server needs to be the latest release (Java, Tomcat, MySQL-Cluster). So I never have the luck, that there are pre-built Debian packages (in the distribution) available. Therefore all the software is downloaded from the project-webpage and built from source.

Now my question is, what is the correct way to install them on my Debian system?

My main problem is, when installing them directly from the source, they are not included in the package management (with aptitude). Checkinstall seems to not really be suggested to be used and equiv also has drawbacks. Is the only correct way to handle this by building my own packages with dh_make and dpkg-buildpackage?

What are you doing if you always need the latest version?

4 Answers 4


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 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:

    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.

  • The last sentence of the first paragraph can be misleading. Please make it clear that you the problem only occurs sometimes. The way you put makes it seems like DDs are generally like that.
    – tshepang
    Commented Apr 11, 2011 at 0:24
  • @Tshepang: Good point. Is it Ok now? Commented Apr 11, 2011 at 6:26
  • Yeah, much better.
    – tshepang
    Commented Apr 11, 2011 at 7:10

You can certainly build your own packages, and that will work. However I would recommend using backports first if what you want is available there.

Backports are Debian maintained and you get security updates for them.


Building your own packages is the way to go (IMHO). Depending on the age of Debian's version of a package and what has changed, this can be as easy as replacing the filename of the source tarball in the package description and in the worst case you can still use it as a template for your own version.


What are you doing if you always need the latest version?

  1. As already mentioned, use backports.

  2. Only a small subset of Debian packages are backported, so I suggest that you use Debian Testing. It offers a nice balance between stability and recency, and is in a sense, like a rolling distro.

  3. If you are a bit more daring, use Debian Unstable. It's claimed to be reasonably stable. Some even go as far as claiming it's more stable than some other distro's "stable" releases. Anyways, Unstable is where new package versions normally land. They normally sit there for about 10 days, to allow for testing, before migrating to Testing.

  4. Even using these two, you might still find yourself not having the latest versions. In that case have a look at Debian Experimental. It's normally used when the new packages are too disruptive for the normal archives (Unstable and Testing).

  5. If Experimental still doesn't have new enough software versions, go look at Ubuntu's PPA's. I've seen software versions there more recent than what all the above archives lack. Use it with caution though, since Ubuntu isn't 100% compatible with Debian (but for most cases, there shouldn't be any issues).

  6. If the above fail, I guess just build your own packages, as mentioned.

  • People saying Debian's unstable is more stable than other distro's stable are joking at best. Unstable changes every day, stable is a fixed repository. Unstable does not mean it'll crash, but it means the developers make a lot of changes to the packages. Stable means it's released, and only security fixes will be added. I never had weird crashes running unstable. I did see packages break and dependency problems after upgrading tho, beware ;-) How that all compares to other distro's "stable" releases is beyond me. There's no "more stable" in this context. It changes or it doesn't. Commented Nov 18, 2011 at 10:10
  • @ArjanDrieman: actually those people are not joking, and in that context they are referring to it being more crash-proof.
    – tshepang
    Commented Nov 18, 2011 at 13:26
  • They're still joking at best. I really have seen people joke about it. A micro distribution flame ;-) I've used a few distro's over time, and have never had weird crashes running any of the other either, People who say that seriously can't back it up with research or stats. That might be ignorance, arrogance, prejudice, anything... but is that better than a joke? Can you tell me who these mysterious "Some" are?, so I can ask them for their research? "Some even go as far"... those are weasel words. What would you like in an answer, facts, or popular opinion and ambiguous claims? Commented Nov 18, 2011 at 21:48
  • 1
    @Arjan Drieman: I actually agree unstable, can 'somtimes' live up to its name. You trade stability for going closer to the edge, anyone who claims it's not the case is disingenuous at best. Overall it is surprisingly stable, but stability is not the highest priority for unstable. I also tend to agree with you, in regards to 'slippery' wordage. It's almost a defense mechanism over here, as any absolute/direct statement is immediately attacked. Commented Feb 17, 2012 at 16:59

You must log in to answer this question.