Adam Heath <[EMAIL PROTECTED]> 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
