On Fri, Oct 18, 2002 at 12:09:14PM -0700, Jeff Bailey wrote:
> On Fri, Oct 18, 2002 at 01:37:51PM -0500, Zed Pobre wrote:
>
> > Attempting to su to root (even from root) with 2.3.1-1 on one of my
> > test systems caused an immediate segfault. Also, attempting to ssh
>
> The ssh problem is probably the known bug that anything using NSS
> needs to be restarted after the libc upgrade. The next package will
> warn about that.
>
> I've been using test versions of the 2.3 package for almost a month
> now and haven't seen any su segfaults. Please investigate that
> further.
The problem was that root uses zsh-static as a shell, and static
libraries got broken by this (a bug has already been filed on
zsh-static about this). Should it be the responsibility of all
packages containing statically compiled binaries to declare an
explicit dependency on the version of libc used to compile them? This
*really badly damaged* a few systems using static binaries out here
when I forgot that I'd manually moved their libcs out of stable and
into testing some time back and never put them on hold for a mass
upgrade of stable/security packages... (yeah, yeah, my fault for not
paying attention, but this wasn't the kind of thing I expected to get
hit by).
I also have to add that I find this to be completely contradictory
behaviour to how I expect static binaries to behave. I compile things
statically when I want them to work properly no matter what version of
various libraries are on the system. If they're not going to work
correctly without a particular version of libc6, might as well stop
providing libc.a and force everything to acknowledge the fact that
they're tied to the system libc.
Okay, the above is inflammatory, and I've debated deleting it with
myself for a little while, but I'm going to let it stand, because some
upgrade path is going to have to be provided by the next release --
and certainly neither this libc6, nor anything compiled against it,
should go into testing until some mechanism is found to prevent
someone running woody with a statically linked shell from apt-get
installing something compiled against the new libc6 and finding
himself unable to log in afterwards to fix all the things that
suddenly broke. Possibly this could be handled by putting new
versions of busybox-static, sash, zsh-static, kiss, and e2fsck-static
(do we ship any other statically linked admin tools?) into woody that
conflict the newer version of libc6, and adding to policy that future
packages that ship statically compiled binaries have to conflict with
any libc6 with a larger minor number than the one used to compile
them, but I truly think there should be a better answer. Is there no
way to get the code of whatever is breaking to be included in a
statically compiled binary, so this doesn't happen again in the
future?
> learning from failures is nice in theory...
> but in practice, it sucks :)
> - Wolfgang Jaehrling
Indeed.
--
Zed Pobre <zed@debian.org> a.k.a. Zed Pobre <zed@resonant.org>
PGP key and fingerprint available on finger; encrypted mail welcomed.
Attachment:
pgpfEhS9TzK4A.pgp
Description: PGP signature