"Julian Mehnle" <[EMAIL PROTECTED]> writes: > First, I think what Daniel Jacobowitz said is entirely true. Why didn't you > start with "testing"?
Sure testing is less likely to trigger this. But testing isn't infallible either. And it shouldn't be mean Debian shouldn't have better error handling. The easier it is for people to manage a Debian system when things go wrong the better, regardless of how much the chances of going wrong are minimized. > > All he had to do was install an older version of libc6 and every other > >package would have been happy. All the infrastructure is there to do this, > >the old packages are all on the ftp/http sites, the package may even be > >sitting in apt's cache. But there's no interface for it. > > Wrong. If, on a "unstable" system, Apt sources for "testing" are also listed > in /etc/apt/sources.list, you can always do a `apt-get -t testing install > libc6` or `apt-get install libc6/testing`. Unfortunately not. apt won't downgrade an already installed package like that. In any case that doesn't really help. What do you do if testing is 2 months old as is often the case with things like mozilla. Or if installing the testing version is exactly what caused the problem? All I want to do is give up on this new version and go to an earlier version, most likely the version I had installed five minutes ago. Downgrading to testing would probably require a whole new set of libraries and more work. > Or, you could create a file /etc/apt/preferences and pin the "testing" version > of the package with a high enough priority. See `man apt_preferences`. Then do > a `apt-get dist-upgrade`. That's about the last place I would send a new user. I read that man page about three times during this crisis before I decided it would be hopeless to try to explain this procedure online. This is what I meant about there not being an "interface". If apt said "Hm, version 1.2 of libc failed to configure, would you like to install the previous version (1.1) from testing and hold back the following packages that depend on the new one (awk, grep, sed) [Yn]?" That would be an interface. If it didn't do anything but "apt-get -f -t testing libc" did that automatically without explaining what it was doing, that would be an interface. Telling people, go edit this random file with to set "pin priorities" for things to arbitrary numbers, find out what package dependencies fail, add those to your list of pin priorities, etc. That's not a useful interface for this case. In any case having the granularity of "stable", "testing", "unstable" really doesn't help. All the package versions are in the pool. I want to be able to tell apt to try such and such version, or at least put back the version I had before and restore whatever other packages it must to satisfy dependencies. > > The only interface for rolling back is switching the entire machine to an > >earlier distribution and telling apt to try to downgrade -- which is unlikely > >to work. And worse, every time you run apt it only downloads and unpacks > >*more* > >packages, all of which, of course, fail as well. > > This is probably one of the worst ways of rolling back few or even a single > package. Well it's the only way a new admin has idea about. He was told to put "stable", "testing", or "unstable" in a spot, that didn't work. So he can try putting a different word in that spot. He can't magically pull "apt_preferences" from thin air and decide to go editing a file he's never heard of. And even if it did, it wouldn't really do what he wanted. I didn't say it was a good idea or that it was going to work. My whole point is that that approach sucks and we should make something more effective rather than leave the admin stuck. -- greg