> Why don't you want to use testing, again?
Well, it doesn't have security updates (well, testing security team is supposed to exist, but it seems somewhat dormant as of late). I may give it a try, though - I'm not running a server so it shouldn't be too bad. Backporting isn't always automatic, packages change with time. Right > now, it is probably not so bad, a simple "apt-get build-dep foo; apt-get > -b source foo" might work because etch has not been released a long time > ago. But as lenny grows near, more and more packages will need manual > backporting. > It wasn't that easy in the cases I was talking about - I had to backport additional packages from unstable to backport what I wanted in the first place. This (auto-backporting all build-deps that stable doesn't have (and their build-deps if necessary), installing the other build-deps from stable, and then building from source and installing the result) is what I was talking about implementing/investigating, not changing "apt-get build-dep foo; apt-get -b source foo; dpkg -i foo*" into one command. Regarding apt-pinning, I didn't use it because ultimately half my system would then be updated to testing/unstable (including things like glibc), going by what apt was saying when I tried it. In that case, why not run testing/unstable (which I may do anyway - though I may go with an Ubuntu Feisty install and a testing/unstable chroot environment).
