Re: A case study of a new user turned off debian
Brian May <bam@debian.org> 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
Reply to: