Re: Bug#139320: marked as done (dpkg: dpkg-deb does not dynamically link libz)

[Jor-el <jorel@trillian.megadodo.umb>]

On Fri, 22 Mar 2002, Wichert Akkerman wrote:

> Wichert wrote:
> > Previously Daniel Quinlan wrote:
> > > Also, given the dependencies on c++ and ncurses already, adding libz which
> > > dozens of packages depend on seems like a trivial addition.
> > The dependencies of dpkg itself are minimal and do not include c++ and
> > ncurses. [...]
> > This change was made on purpose to make sure that dpkg will be
> > useable on broken systems where libz might not be working correctly
> > and to make it easier to bootstrap a system.
> 
> Not depending on libz doesn't make it any easier to bootstrap a system,
> you already get all the complexity just by needing libc. (Either by
> requiring you to unpack the libs without dpkg first somehow, or by
> requiring you to have appropriate libraries in the host system)
> 
> Cheers,
> aj, debootstrap author
> 
Hi,

	Statically linking does make a difference when doing a port to
another OS. I am, for instance, working on a port to AIX and AIX doesnt
come with a libz. So, people would be able to take the AIX native binary
package for dpkg and dpkg tools that I build for AIX and install it on AIX
without having to put libz on there first. libz could then be installed
from the .deb version.

	I think some of the opinions in this thread are assuming that a
new port is a port to Linux on a new hardware architecture. That is not
always the case. Even if it is the case, IMHO the most attractive way of
porting is piece (sp?) by piece (as opposed to doing everything at once)
and this needs the initial set of run time dependancies to be as small as
possible.

	As a porter, I think that the dpkg maintainers are on the right
path.

Regards,
Jor-el