Re: SASL/LDAP/DB dependency hell. (was: Accepted cyrus-sasl 1.5.27-3.4 (i386 source))
Andreas Metzler <firstname.lastname@example.org> writes:
> 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
> Actually it is much simpler, many packages are simply not compileable
> libldap2-dev depends on libsasl-dev 
> libsasl-dev depends on libdb2-dev (>= 126.96.36.199-7) 
> libdb3-dev conflicts with libdb2-dev
>  introduced in response to #164791
>  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. I'll hold off uploading it until about 11 AM Pacific
daylight time Thursday morning, though, so somebody can tell me if I'm
Actually, though, it seems libdb4.0 and libdb4.1 don't have versioned
symbols -- so if a program links against -lsasl and -ldb4.0 there's
still a possibility of problems afaict.
Daniel Schepler "Please don't disillusion me. I
email@example.com haven't had breakfast yet."
-- Orson Scott Card