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

Re: Changes in dpkg Pre-Depends

On Sat, 2010-02-20 at 10:07:45 +0100, Stefano Zacchiroli wrote:
> On Sat, Feb 20, 2010 at 12:15:10AM +0100, Guillem Jover wrote:
> > Second, I'd like to switch from statically to dynamically linking
> > against zlib and libbz2, eventually liblzma too (affecting dpkg-deb)
> > and libselinux (affecting dpkg itself only on Linux). Here's the
> > arguments I know of against and in favour, with rebuttals:
> I'm personally convinced by your arguments. Still, I'd like if you
> consider the transitional idea of having---say, for a release---two
> different binary packages shipping dpkg: "dpkg" (essential: yes) and
> "dpkg-static" (essential: no), the latter containing a fully statically
> linked version of dpkg, coming as /usr/bin/dpkg-static.
> I've seen this for other safety-critical tools, e.g. the dar backup tool
> which comes both as "dar" and "dar-static". I personally don't believe
> there would be *much* use of "dpkg-static", but having it around for a
> release would enable to see if/how many (paranoid) people actually
> install it. Would that make sense in your opinion? Would it be worth?

I don't think this would be worth it, as Marco has also said, if the
system is hosed but you can still get to the point of obtaining a
package to install you might as well just obtain the broken files.
Of course you might have it already on apt's cache, but that's not
usually the case when you need it. :)

Also I'm guessing if it's there some people will end up installing it,
either on purpose or by accident, and trying to remove it later might
find some resistance (from the former).

Something that came to me after having sent the mail is that we have
programs way more critical that are dynamically linking with all used
libraries, like the ones involved in the boot sequence: init (libc,
libsepol, libselinux), mount (libc, libblkid, libuuid, libsepol,
libselinux), udevd (libc, libselinux) and there's not been the need
to provide static versions for them, and I would tend to think an
unbootable system is trickier to recover than one where you cannot
install new packages.


Reply to: