Brian May <[EMAIL PROTECTED]> writes: > On Mon, Nov 03, 2003 at 03:05:56PM -0500, Greg Stark wrote: > > What started the chain of events was that a fairly routine minor bug bit the > > latest libc6 release. He's an experienced sysadmin though and wasn't the > > least > > What (probably; I am guessing a bit) continued the chain of events: > ...
All wonderful guesses, but not really at all relevant to what Debian could do better to handle the situation. All I'm trying to do is look at what I did as an experienced Debian user and trying to figure out a) why a new Debian user's instincts were all wrong, b) why the existing tools made the problem worse, and c) why the tools can't just do what I did or at least make it easier to reach the right approach. The main difference between apt's error handling and my own was that I was aware that I could simply roll back to a version other than the current "unstable" or "testing". There are many versions in between and rolling back to "testing" was overkill and would have caused tons more problems than it would have solved. In the case of someone tracking "testing" there isn't even any such option, (rolling back to "stable" being laughable). So all it would take to make the tools handle this would be to somehow make apt aware of more revisions of packages. They're all in the pool after all. Short of making some king of humongous mega-Packages file with every revision of every package -- which apt wouldn't scale up to anyways -- they're currently unavailable to APT. The low hanging fruit here would be to have APT keep packages you had installed yourself in the cache rather than immediately discarding them as soon as they're upgraded. At a minimum keeping one extra revision would at least let you roll back. Something more flexible keeping old revisions for n days after being replaced would be even cooler. Currently recovering from a package failure means manually downloading a single .deb and using dpkg to install it, and then tracking down the right versions of the dependencies for that .deb, and trying to install those, and ... basically reverting to RedHat-style manual dependency resolution; If apt kept even a single old revision in its cache then rolling back could be as simple as apt-get install -t previous libc6 or perhaps a little less automatic, apt-cache show libc6 to list the available revisions then explicitly apt-get install libc6:2.3.2-8 Actually this wouldn't really have helped my friend at all because he was unlucky enough that the *first* version of libc6 from unstable that he saw happened to be the buggy one. That doesn't really happen that often to libc6 so he had particularly bad luck there. -- greg
