[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: List of bugs that *must* be fixed before releasing Slink

On Mon, Feb 15, 1999 at 11:42:17AM -0800, Guy Maor wrote:
> > dpkg and libdpkg are in the same package both will be upgraded at the
> > same time
> Not exactly at the same time.  There is some interval at which dpkg
> has upgraded one and not the other.  If some fatal error occurs then,
> you'll have mismatched versions.  The same fatal error occurring in a
> staticly linked dpkg wouldn't be a problem.

I tried upgrading to glibc2.1 but got something wrong and the upgrade
didn't happen as planned (a number of factors), fortunately I had a
backup of /lib if I needed it.  Unfortunately things happened and before
I realized the severity of the problem I ended up having to reboot.  The
resulting system wouldn't boot single user to fix the problem.  Well it
booted but mount wouldn't work to remount / as rw so I could replace /lib
with the copy I backed up for just such an emergency.

Now if packages such as sysvinit and mount and sh are not static, why
should dpkg be?  If libs are screwed, libs are screwed.  If dpkg is made
static, that's not gonna help me when mount is screwed.  However if mount
is fine and dpkg is screwed, I can probably fix dpkg.  =>

I don't mean to totally negate your proposal here, however if we are
going to fix this problem then by all means let's fix it right.  We
simply cannot build everything in base as static, the base disks need
them built dynamic.

My suggesting is then that we build some of the base packages as
${PACKAGE} and ${PACKAGE}-static.  High on the list for this are:
sysvinit, e2fsprogs, util-linux, gzip, tar, sed, ash, some version of vi,
testutils, etc..  Stuff that would be REQUIRED to fix a broken system. 
Once we have that, then we can talk broken dpkg reasonably.

This stuff may be arranged in such a manner so it exists if needed but is
not used under normal operation..  ie, different paths are used for
maintaining the system than running it.  I certainly would not want
/bin/sh to be a static linked bash, but I would want init to be static
and I would want single user mode to give me a static shell, etc.

I tried to bring this up on -policy and for the most part my message was
ignored (probably read by many, but nobody has thought to comment, agree,
disagree, whatever)  I consider it an important issue all the same.

Anticipation is the sweetest form of torture...

Reply to: