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?
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
(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
You can replace the steadfast.net mirror with whatever you want. I'd recommend using
You can also add a
To install the testing version of a package, simply use
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.
and then install what you need with
Be very very careful if you install stuff that has plenty of dependencies. Preferably don't do this on production.
You can as well try your luck at backports or similar repository.
Define the default level that the system should 'safe-upgrade' to in the /etc/apt/preferences file:
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:
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').
So to install that package, all you have to do is:
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.
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:
Another way, that could prevent installing too many dependences from Testing or Sid, is this: you tell apt-get to get the source of the package from Testing or Sid and create a package for your system using Debian tools (no need to manually tinker with sources).
I have been doing it for an extended period of time to be confident in saying it is safe enough and can be made convenient. With the below setup stable version will installed by default, however Aptitude will also allow you to choose backported or unstable version if so desired:
There are four things that need to be edited, the default pinning release needs to be set, the sources need backports and unstable added, lowering the pinning priority of backports/unstable packages, and the aptitude display settings needs to be modified to display pinning.
# deb cdrom:[Debian GNU/Linux 6.0.0 _Squeeze_ - Official Multi-architecture amd64/i386 NETINST #1 20110205-14:45]/ squeeze main deb http://ftp.us.debian.org/debian/ squeeze main deb-src http://ftp.us.debian.org/debian/ squeeze main deb http://security.debian.org/ squeeze/updates main deb-src http://security.debian.org/ squeeze/updates main # squeeze-update, previously know as 'volatile' deb http://ftp.us.debian.org/debian/ squeeze-updates main deb-src http://ftp.us.debian.org/debian/ squeeze-updates main # squeeze backports # http://backports.debian.org/Instructions/ deb http://backports.debian.org/debian-backports squeeze-backports main # unstable # http://wiki.debian.org/AptPreferences deb http://ftp.us.debian.org/debian/ unstable main deb-src http://ftp.us.debian.org/debian/ unstable main # non free ex. sun java #deb http://ftp.us.debian.org/debian/ squeeze non-free #deb-src http://ftp.us.debian.org/debian/ squeeze non-free
# Package pinning priorities # See http://wiki.debian.org/AptPreferences and http://manpages.debian.net/cgi-bin/man.cgi?query=apt_preferences # # In nut shell highest PIN gets installed # # Pining default are as follow which are in addition to our settings: # 990 - for version that are not installed but DO belong to our `APT::Default-Relase "stable"` setting. # 500 - for versions that are not installed and do not belong to the target release # 100 - for packages that already installed, this also means other versions of same package # 1 - for experimental packages; packages with "NotAutomatic: yes" # # Our Pinnings # 400 - backports that can safely be installed without the need to update other packages # 50 - unstable packages, install forced in the details screen, can result in conflicts Package: * Pin: release n=squeeze-backports Pin-Priority: 400 Package: * Pin: release a=unstable
Aptitude::UI::Package-Display-Format "%c%a%M %p %Z %v %V %i";
If your selection of packages is more involved or the installation will be repeated on multiple machines, you might consider setting up a private repository that mirrors a subset of the official repositories. This requires a bit of work to configure the repository but the reward is easy to maintain with a bare minimum of configuration on each client and repeatable results when doing dozens of installations. I find this helpful even when only one or two packages are being installed, and use this method for automating and maintaining cloud installs. A single server on a cheap VPS can handle dozens of private repositories.
To configure your private repository server:
Then configure your web server of choice to serve the static repository files. Possibly protect the repository with a security certificate and basic authentication.
To automatically maintain your private repository and pull in updates from upstream, put the above in a script and run from a cron job.
To configure your client machine, on your client machine:
To maintain your client machine and pull in all of your private repository updates, on your client machine: