package manager aspect Re: how to make Debian less fragile (long and philosophical)
As I said in the original message:
Sash isn't installed.
It's not "important", so it isn't there. OK, on my system it could be, but
most people aren't going to think about disaster until it strikes.
This is 1/2 of my original complaint dealt with, if sash is important.
The other half is the excessive dependency of the package manager on
complex and frequently upgraded packages.
The recent bash/readline break illustrated THREE points of failure
on my system (never mind it is unstable, look at the theoreticaly
dependencies here):
#1-- circular bash/libreadline caused re-install of bash to fail,
since the package manager depends on bash, and it had been
removed, so its dependency couldn't be installed, and it
couldn't be re-installed.
BASIC FAULT: package manager depends on complex runtime dependency
which under some circumstances it removes.
#2-- libC upgrade attempted next, libC removed, re-install failed
since bash wasn't present to run the install script
BASIC FAULT: package manager depends on complex runtime dependency
which under some circumstances it removes (bash); and
package manager continues after catastrophic failure of
itself (loss of bash)
#3-- apt-get, dpkg, ftp, etc., fail because libC removed, so package
manager cannot continue and quits. unable to restart package
manager due to loss of libC.
BASIC FAULT: package manager depends on complex runtime dependency
which under some circumstances it removes (dynamic glibc)
ANY problem during the re-install of a critical part of the package
manager, such as bash or glibc or anything else, will lead to a failure
of the package manager.
The important thing here is not "this particular problem", the important
thing here is ANY problem--there is a window in time opened up when the
package manager is highly vulnerable (when bash is gone, when libC is gone,
and so forth) and I want that window to be as small as possible; and I
want the things that happen during that window to be as simple as possible:
all so that the probability of failure is the smallest it can be.
I am arguing that the runtime dependencies in the package manager should
be seriously reduced, both by taking care to bootstrap critical parts
of itself; and by eliminating gratuitous runtime dependencies such
as dynamic linking introduces.
Also, I am arguing a move to dependency on more stable, and less
frequently changed packages (such as ash) rather than less stable,
and more frequently changed packages (such as bash).
All of these proposals eliminate whole categories of failure points,
the absence of any one of which would have prevented the hosing of
my system; and the hosing of other peoples systems under similar
circumstances.
Justin
On Wed, Aug 18, 1999 at 06:47:10AM -0400, Michael Stone wrote:
> On Wed, Aug 18, 1999 at 02:25:56AM -0400, Justin Wells wrote:
> > OK, it was a bit of a troll--but I really do set up backup roots on
> > important systems. I don't view them as live recovery options though,
> > I view them as an alternate way to reboot a failed system, if it
> > is hosed so badly that it won't even boot. I consider this preferable
> > to floppies, since they're always in the drive, and since floppies
> > are highly unreliable. (I have boot floppies too, or more often boot
> > CD's these days--I just like not having to use them).
> >
> > My problem with the alternate root is you would still need at
> > least a couple of statics lying around to make use of it for
> > live recovery:
> >
> > su, sh, mount
> >
> > That would be an absolute minimum. You need to be able to acquire
> > a root shell (su and sh), and you need to be able to mount the
> > alternate root.
>
> Troll, troll, troll. That's what sash *already does*. That's been
> pointed out *many times*. You have yet to explain why that won't work
> for reasons other than *personal preference*.
>
> Mike Stone
Reply to: