how to make Debian less fragile (long and philosophical)

[Justin Wells <jread@semiotek.com>]

I think the recent problem with bash and libreadline are symptoms of 
a deeper problem with the way the Debian distribution is organized.

Essentially, it's this:

   -- Core system management tools, including the package manager suites
      and anything they depend on (therefore, including /bin/sh) 
      should be availble on / as statically linked binaries. Dynamic
      versions of these same programs may be available elswhere for
      normal use, but should not be used by core system management tools.

Here is my reasoning, followed by some discussion of it:

   1. During system failure the system administrator should have 
      access to the basic tools necessary for system repair. Since
      the system is damaged, it is unreasonable to assume that /usr 
      has been mounted, and it is unreasonable to assume that the 
      link loader is working or that the C library is intact. 

   2. The static binaries should be available on /, since that is
      guaranteed to be present if the system can boot at all. And
      in particular, static binaries should not be available only
      on floppy as the administrator may be working from remote.

   3. The package manager should not depend on anything it is 
      operating on. If it does, you always face the risk of the
      package manger destroying its own ability to function. 
      Instead, upgrading the package manager itself should be
      viewed as a bootstrapping problem: there are a variety 
      of solutions--installing into a different directory, 
      clever use of symlinks, etc.

   4. The core system tools should be subject to more extensive QA
      testing than anything else. This is difficult when there are 
      dynamic dependencies since any change to any dynamic library
      would require a new round of testing. With static binaries, you
      only need to retest extensively when the binary itself changes.

   5. There is no performance issue here, since the package manager
      is not a heavily used tool. There will generally be only
      one copy of it running, and it will probably not be run 
      more than once or twice a day. Dynamic linking is fundamentally
      an optimization, and optimizations are wrong when they 
      increae complexity and reduce reliability without providing
      any actual performance benefit.
     
Having the package manager depend on statically linked binaries only
would have avoided the recent bash/libreadline catastrophe, which 
utterly ruins the system of anyone attempting an upgrade from 
slink to potato (bash and the C library get removed and not
re-installed, leading to a level of failure where not even apt-get
works.)

If apt-get were statically linked, it could in theory be used 
to repair the damage. If bash were statically linked, it would 
not have depended on libreadline in the first place. Also, if 
bash were statically linked there would have been a root shell
available for single-user mode operation, and enough other tools
around that the system administrator could have fixed the problem
without rebooting (or needing to be physically present at the
machine to insert a rescue floppy).

I am not suggesting that the bash people normally use should be 
statically linked. I am suggesting that a statically linked version
be available. Perhaps /bin/bash is statically linked, but there
exist a /usr/bin/bash that is dynamic (and potentially more up to
date but less well debugged).

This approach is essentially what is done in many other OS's, and
I think we should learn from 30 years of Unix experience and do 
something similar. 

For example, FreeBSD has a set of statically linked tools in /stand,
including its package manager. It goes even further, and everything
in /bin is actually statically linked--on the theory that you might
have / mounted but not /usr. FreeBSD provides a dynamically linked
bash in its /usr/local directory (don't ask why it's /usr/local
instead of somewhere else--a FreeBSD oddity that Debian avoided).

Whether Debian should go as far as making everything in /bin static
I don't know--that would be a substantial change, though it would 
have some benefits. However, perhaps not enough benefits to warrant
the change, and there would be a few drawbacks too (binaries in /bin
get used more frequently, possibly in situations where performance
is a real issue.)

It's clear that the current reliance on dynamic binaries for basic 
level system maintenance is dangerous, and makes the Debian OS
fragile and unreliable. (Evidence: my slink system hosed itself
when I tried to upgrade it to potato, leaving it utterly unusable
without even a shell for single user mode, or a working C library).

I would like Debian to be the most stable, most reliable Unix, with
the smallest cost of ownership. In order to achieve that, this kind
of fragility must be exorcised from the distribution.

Does anyone here take this seriously?

Or is stability, reliability, and therefore cost-of-ownership a 
non-issue with the Debian group? 

Justin Wells