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

Re: SASL/LDAP/DB dependency hell. (was: Accepted cyrus-sasl 1.5.27-3.4 (i386 source))

On Wed, Apr 09, 2003 at 09:26:12PM -0700, Daniel Schepler wrote:

> > On Tue, Apr 08, 2003 at 07:07:33PM -0400, Richard A Nelson wrote:
> > > Why was this rebuilt with libdb2-dev ?  Shouldn't we be trying to
> > > get things to db4.1 at this point ?  I'd think db3 at a minimum.

> > > This isn't just idle curiosity either, SASL impacts MANY packages -
> > > most MTAs and anything using OpenLDAP.

> > > If we don't agree on a minimum, or at least a preferred lib... we're
> > > going to have packages linked against 3 different levels - not fun

> > Hello,
> > Actually it is much simpler, many packages are simply not compileable
> > anymore:

> > libldap2-dev depends on libsasl-dev [1]
> > libsasl-dev depends on libdb2-dev (>= [2]
> > libdb3-dev conflicts with libdb2-dev

> > [1] introduced in response to #164791
> > [2] introduced in response to #168993

> > libtool strikes again, quoting from the report
> > | /usr/lib/libsasl.la contains -lpam as a dependency, so -lsasl can't be
> > | linked using libtool without libpam0g-dev being installed.

> > This hits almost anything linking against libldap2, including postfix
> > (db3), apache2 (db4.1), xemacs21(db3), sendmail (db3), KDE (db4.0),

> I'm going to prepare a new NMU in which libsasl-dev has that
> dependency changed to "libdb2-dev | libdb-dev", which should satisfy
> the libtool issue while still allowing libdb4.0-dev, etc.  Hopefully
> because of the versioned symbols in libdb2 this won't result in
> breakage.

Whether or not it results in breakage, it still compounds the
libtool-induced problem of linking against libraries that aren't needed.
If you allow this dependency to be satisfied by any version of
libdb-dev, we may end up with binaries for applications that don't
directly use libdb *at all* being linked against an extraneous version
that happens to be on the system at the time.

A much saner solution would be to simply stop shipping the .la file in
libsasl-dev.  Its only reasonable application on Linux systems is for
static linking, and even there it's a convenience, not a necessity.
Since Debian doesn't ship statically linked binaries (with few
exceptions), and few users are likely to be statically linking libsasl
anyway, I think this is the best choice.  Note that OpenLDAP 2.1
currently uses the .la file (via ltdl_open()) for dynamic loading of
libraries, but I think work is being done to correct this unnecessary
dependency as well.

Steve Langasek
postmodern programmer

Attachment: pgpH5RZbUa3FF.pgp
Description: PGP signature

Reply to: