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