How can I run Debian stable but install some packages from testing?

Question

Say you're running a server and you don't want to upgrade to Testing (Squeeze) from Stable (Lenny) to just install a required package or two.

What's the best way of installing only certain packages from Testing?

Answer 1

answer no longer applies to the latest debians; please see another answers

in /etc/apt/apt.conf add

APT::Default-Release "stable";

in /etc/apt/sources.list - add urls for testing / unstable sources

run

apt-get update

and then install what you need with

apt-get -t testing install something

be very very carefull if you install stuff that has plenty of dependencies.. preferebly dont do this on production.

you can as well try your luck at backports or similar repository

Answer 2

apt_preferences

Define the default level that the system should 'safe-upgrade' to in the /etc/apt/preferences file:
man apt_preferences

There's a lot you can do with apt_preferences but for the sake of simplicity...

I needed to install a single package (autoMysqlBackup) that was only available in Testing. The solution was to add the following to /etc/apt/preferences:

Explanation: Uninstall or do not install any Debian-originated
Explanation: package versions other than those in the stable distro
Package: *
Pin: release a=stable
Pin-Priority: 900

Package: *
Pin: release o=Debian
Pin-Priority: -10

With multiple repositories added to /etc/apt/sources.list aptitude will now only upgrade to your specified release even though the later release repos are listed (in this case 'stable').

deb http://mirror.aarnet.edu.au/debian/ lenny main
deb-src http://mirror.aarnet.edu.au/debian/ lenny main
deb http://mirror.aarnet.edu.au/debian/ squeeze main
deb-src http://mirror.aarnet.edu.au/debian/ squeeze main

So to install that package, all you have to do is:

$ aptitude install -t testing packageName

Answer 3

The debian documentation is extensive in the subject and I strongly advise to dig in as it will truely unveil the beauty of the debian system.

Have a look at How to keep a mixed system, it will explain all you need tio know.

Answer 4

For what it's worth, the general advice I've always seen is "Don't mix stable with anything." Most of the mixed systems tutorials are for mixing testing and unstable.

The reasoning seems to be that if you mix stable with testing, very basic packages (like libc6) will require updates (in order to install software from testing), and once these basic packages move to testing, the whole system can drift that way.

Here are two alternatives:

1. Use Backports.
2. Install a source line from testing, and try to build the later version you want from source.

Answer 5

Many people seem to be afraid of mixing stable with testing, but frankly, testing is fairly stable in its own right, and with proper preferences and solution checking, you can avoid the "stability drift" that puts your core packages on the unstable path.

"Testing is fairly stable??", you ask. Yes. In order for a package to migrate from unstable to testing, it has to have zero open bugs for 10 consecutive days. Chances are that, especially for the more popular packages, somebody is going to submit a bug report for an unstable version if something is wrong.

Even if you don't want to mix the environments, it's still nice to have the option there in case you run into some thing that requires a newer version than what is in stable.

Here's what I recommend for setting this up:

First, create the following files in /etc/apt/preferences.d:

security.pref:

Pin: release l=Debian-Security
Pin-Priority: 1000
Package: *

stable.pref:

Pin: release a=stable
Pin-Priority: 995
Package: *

testing.pref:

Package: *
Pin: release a=testing
Pin-Priority: 750

unstable.pref:

Package: *
Pin: release a=unstable
Pin-Priority: 50

experimental.pref:

Package: *
Pin: release a=experimental
Pin-Priority: 1

(Don't be afraid of the unstable/experimental stuff here. The priorities are low enough that it's never going to automatically install any of that stuff. Even the testing branch will behave, as it's only going to install the packages you want to be in testing.)

Now, creating a matching set for /etc/apt/sources.list.d:

security.list:

deb     http://security.debian.org/         stable/updates  main contrib non-free
deb     http://security.debian.org/         testing/updates main contrib non-free

stable.list:

deb     http://mirror.steadfast.net/debian/ stable main contrib non-free
deb-src http://mirror.steadfast.net/debian/ stable main contrib non-free
deb     http://ftp.us.debian.org/debian/    stable main contrib non-free
deb-src http://ftp.us.debian.org/debian/    stable main contrib non-free

testing.list: Same as stable.list, except with testing.

unstable.list: Same as stable.list, except with unstable.

experimental.list: Same as stable.list, except with experimental.

You can replace the steadfast.net mirror with whatever you want. I'd recommend using netselect-apt to figure out the fastest mirror, and use that for your first choice. The ftp.us.debian.org can be used as a backup. It's also important to use the terms stable, testing, unstable, etc., instead of squeeze, wheezy, sid, etc., since stable is a moving target and when it comes time to upgrade to the latest stable, apt/aptitude will figure that out automatically.

You can also add a oldstable in sources.lists.d and preferences.d (use a priority of 1), though this moniker will tend to expire and disappear before the next stable cycle. In cases like that, you can use http://archive.debian.org/debian/ and "hardcode" the Debian version (etch, lenny, etc.).

To install the testing version of a package, simply use aptitude install lib-foobar-package/testing, or just jump into aptitude's GUI and select the version inside of the package details (hit enter on the package you're looking at).

If you get complaints of package conflicts, look at the solutions first. In most cases, the first one is going to be "don't install this version". Learn to use the per-package accept/reject resolver choices. For example, if you're installing foobar-package/testing, and the first solution is "don't install foobar-package/testing", then mark that choice as rejected, and the other solutions will never veer to that path again. In cases like these, you'll probably have to install a few other testing packages.

If it's getting too hairy (like it's trying to upgrade libc or the kernel or some other huge core system), then you can either reject those upgrade paths or just back out of the initial upgrade altogether. Remember that it's only going to upgrade stuff to testing/unstable if you allow it to.