First, a few brief statements of introduction.
(1.) It is my opinion that Stable (Etch) should not be run as part of a mixed system under any circumstance. The developers have gone to great lengths to design and release a trouble free environment for people who want it to "just work," and introducing elements from outside repositories is just undermining that design. If you need a newer version of a program than is available from the Stable repositories, check to see if it is available from backports.org. (Instructions.) If it is not, you should compile and build it yourself within your own installation. (Assuming you want a package from Lenny in Etch, and your sources.list file contains a line like this...
deb-src ftp://ftp.us.debian.org/debian/ testing main non-free contrib
...run "# apt-get source <programname>" and see if the package builds against Etch first. Most of the time, it will.)
People who find themselves needing this sort of upgrade with any regularity should upgrade to Testing.
(2.) Not everyone should be running a mixed system. A commonly quoted piece of Debian Unstable advice is, "If it breaks, you get to keep both pieces." By the nature of your decision to run a mixed system, you have considered as many ramifications as possible, and judged yourself capable of managing it. The "normal" scenario would be to run a system that is primarily Testing with just a few applications drawn from Unstable. Mixed systems are particularly suitable for home desktops and hobby boxes which do not include critical data for which you have no backup, or on systems for which occasional downtime is acceptable. This essay is intended to show how it is done, in principle, not how well it will work for you.
(3.) Any examples I include here will assume that your mixed system is Testing/Unstable. Testing/Unstable mixes are very common and generally OK, since the way testing is updated is very similar to mixing Testing and Unstable. As the Stable release matures, Stable/Testing or Stable/Unstable mixes get more and more risky.
I prefer Aptitude as the program installer, and examples of Apt commands will reflect that. If you are capable of running a mixed system, you are capable of translating that to apt-get, or even Synaptic or Adept. If you are determined to run a mixed-Stable system, you should be able to make the necessary translations for that, as well.
Getting down to business...
The first source of information is the official Apt Howto. You probably have it installed on your system someplace and it should be bookmarked (along with the Aptitude User's Manual).
There are two regularly used methods of accomplishing this "mixing." First, the easy to understand, but "incorrect" method. We'll assume you are starting out with a sources.list file that looks something like this:
That is a standard Testing (Lenny) installation with the Unstable (Sid) repository readily available, but commented (#) out, in case you decide to "mix" something.deb http://ftp.us.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.us.debian.org/debian/ testing main
deb http://www.debian-multimedia.org testing main
deb http://security.debian.org/ testing/updates main contrib
deb-src http://security.debian.org/ testing/updates main contrib
#deb http://ftp.us.debian.org/debian/ unstable main contrib non-free
#deb-src http://ftp.us.debian.org/debian/ unstable main
When you discover that your preferred Desktop UI (Ratpoison) has a newer version in Unstable, and you just can't wait, you simply change the commenting, thusly:
# aptitude update#deb http://ftp.us.debian.org/debian/ testing main contrib non-free
#deb-src http://ftp.us.debian.org/debian/ testing main
deb http://www.debian-multimedia.org testing main
deb http://security.debian.org/ testing/updates main contrib
deb-src http://security.debian.org/ testing/updates main contrib
deb http://ftp.us.debian.org/debian/ unstable main contrib non-free
deb-src http://ftp.us.debian.org/debian/ unstable main
# aptitude install ratpoison
... change the commenting back to its original form, "# aptitude update" ... again, and there you are; safely back in Testing with the new Desktop UI from Unstable.
Unfortunately, there are other considerations. Binary applications don't come from external repositories all by themselves. Usually, there are associated dependencies accompanying them which are upgrading libraries, etc. on your system, and which may or may not affect other installed programs. Depending on the difference between your installed system and the repository from which you are upgrading, the residual effect can resemble a veritable tsunami, upgrading half of your system.
The first key to resolving that problem is to pay attention to what dependencies are going to accompany your upgrade. If you decide to reverse an upgrade, you will need to know exactly what was replaced.
There is another issue, as well. Suppose that the day after you have happily updated your Desktop UI from Unstable a horrible security problem is discovered in it. A new version will be uploaded to Sid, but you will know nothing about it. So ... we've got to be a little more sophisticated.
Doing it right:
Let's go back to my sample sources.list file:
Notice that the comments have now been removed from both Testing and Unstable. An "# aptitude update" (or "$ aptitude search") now would recognize all the available files in both Testing and Unstable. However, an "# aptitude upgrade" would upgrade everything to Unstable since that is where it would find the newest applications. That is not what we want.deb http://ftp.us.debian.org/debian/ testing main contrib non-free
deb-src http://ftp.us.debian.org/debian/ testing main
deb http://www.debian-multimedia.org testing main
deb http://security.debian.org/ testing/updates main contrib
deb-src http://security.debian.org/ testing/updates main contrib
deb http://ftp.us.debian.org/debian/ unstable main contrib non-free
deb-src http://ftp.us.debian.org/debian/ unstable main
Here is the key. We need to let Apt know which is our preferred update repository. That information comes from the /etc/apt/apt.conf file. If it doesn't exist, create it. It needs to include this line:
APT::Default-Release "testing";
With that in place, aptitude will first look at testing, and if it sees the program you have identified, it will look no further. In our scenario, since we know we want our application from Unstable, our command will be:
# aptitude install -t unstable ratpoison
All this is a beautiful thing, but it's not foolproof. At the beginning of the essay, I said, "...you have ... judged yourself capable of managing it." That "managing" is what we will look at next.
Other Considerations
Suppose that Testing is the default release, but the application in which we're interested exists only in Unstable. In that case, Aptitude will happily install it (and its dependencies) without any particular warning. This is further complicated by the fact that those dependencies, along with any programs you chose by name to install, are "marked" by Apt as OK to upgrade from Unstable. From now on (until your Unstable package moves to Testing), those programs will be updated from Sid as the updates become available.
The critical result of that behavior is that it will behoove you to be aware of what programs have been installed from your secondary repositories, so that you can be alert for subsequent upgrades from that repository which can easily happen without your realization. (Note: The best way I have discovered to check exactly what packages are currently installed from unstable is: $ apt-show-versions | grep unstable )
The next step in preventing such unforeseen updates is "pinning," but that is just beyond the scope of this Howto.
(Insertion: There is quite a bit of discussion in the comments below about the need for an /etc/apt/preferences file, and the "pinning" instructions it contains. I have been watching my own system very closely to see how a package upgrade is handled once you have chosen to upgrade it from Unstable. My considered opinion, at this point, is that /etc/apt/preferences is not necessary, unless you feel that you need absolute control over the source of future upgrades to the package in question.
My observation is that, without pinning, a package installed from Unstable will continue to get upgrades from unstable until it is migrated from Unstable to Testing. Once that happens, aptitude will change it's source for that package back to the default release (Testing). IMO, that's the way you should allow it to work. /Insertion.)
Many people also recommend the installation of apt-listbugs. That program will identify any bugs filed against a program you have requested before aptitude actually installs it. If you feel that a reported bug might affect your system adversely, it gives you the opportunity to back out at the very last moment. I don't use it myself because I am confident that aptitude's remove process will do a good job of reversing any installation disaster that I encounter.
One of the ways you can make yourself very useful running a mixed Testing/Unstable system is by reporting bugs. It's certainly not in any way obligatory, but if you have time on your hands, it's nice. Certainly, the developers and maintainers provide some testing before the applications are moved to Unstable, but their hardware and usage patterns are not just like yours, and bugs do emerge in specific environments. You can even simply request a new feature by sending a bug report with the "wishlist" severity.
A nice Howto for using the Debian Reportbug tool can be found here. You might want to be aware that the editing tool incorporated into reportbug seems to be vim, so if you're not comfortable with that, "vimtutor" might be a better first step. At the very least, you would be well advised to get accustomed to using the Debian Bug Tracking System.
All this is not intended to discourage people from setting up a mixed system, but rather to encourage them to go into it with eyes fully open. My "safe" system is a Testing/Unstable mix, but I'm very careful, indeed, about what is going on there during my weekly upgrades.