Bug#139320: dpkg: dpkg-deb does not dynamically link libz

[Daniel Quinlan <quinlan@pathname.com>]

Adam Heath <doogie@debian.org> writes:

> First, dselect and dpkg will be split post woody, so the dpkg.deb
> will only depend on libc6.
>
> Second, having external library dependencies in dpkg is something we
> (Wichert and I) would rather not have.

Why?  In older versions of Debian, fewer packages used libz
dynamically, but now almost everything does (except for sash which is
completely static for recovery).  It's hard to imagine any system that
doesn't have it already, but even if it didn't, so what?  This is how
Debian is designed.  You don't work around dependencies by including
your own version of everything.  If it isn't, this should be policy.

Next, I have to use Red Hat at work (and once administered hundreds of
workstations running it).  rpm is dynamically linked against libz and
not once has that dependency this ever been an issue.

In small embedded systems, always using dynamic libraries is an even
bigger issue (to save space).  In larger systems, realistically
speaking, you're always going to have libz from some package (ssh,
cvs, X11, lynx, and dozens more).

I can't think of a single advantage to linking libz statically.
External library dependencies are not a disadvantage, they're an
advantage.

> Third, linking against the library allows us to not have to exec
> gzip, which is the way the original code worked.
>
> For extracting debs, the only exec that happens is the one for
> dpkg-deb.  And, since that file is part of dpkg itself, it will
> always be working.

I didn't mention gzip as a possibility, so this isn't really relevant.
For what it's worth, I completely agree that avoiding an exec gzip is
a good thing.

> I would rather tag this bug wontfix, or close it, but I'll wait for
> Wichert's take on it first before doing so.

Thanks.

- Dan