Re: A case study of a new user turned off debian
i like your ideas a lot! i wasted some time too trying to downgrade, after putting on a broken
it would be very good, if the whole package storage and apt thing would work a little better
1. defined number of versions of debian packages stored on ftp.debian.org
2. apt-cache storing a defined number of versions
(already doing it, it think, and this thing really saves bandwith)
3. apt should have an easy interface to access these packages
4. apt-cache should be able to use every source apt can use
(our sources.list contains now direct things, and proxy things,
which we do not like).
5. the best feature would be, if two (more) versions of a packge could
be installed, and switched at runtime, maybe by linking.
this would be very good for companies.
but i admit, this does not help the newbie, but it would help repairing a broken system. there you
always know which one broke your system.
for the newbie, i recommend debian and apt based www.knoppix.org, a debian based system, where you
- enter cd, and boot, or
- install this thing also to hard-drive, or
- just use it to figure out how your
debian should be configured
(necessary package versions, etc)
definitly one of the best desktop systems i know, runs on newest (desktop) hardware.
Brian May <firstname.lastname@example.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.
Do you Yahoo!?
Free Pop-Up Blocker - Get it now