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

Re: Versioned Symbols

* Wichert Akkerman (wichert@wiggy.net) wrote:
> Previously Stephen Frost wrote:
> >   We need to make a decision on how to properly handle multiple library
> >   versions ending up linked into the same process.
> I think what we should do is simple: 'do not do that'.

If we do that then we will continue to run into problems.  See #177868,
#178061, #177764 (which were all merged by Colin when I pointed out they
were all the same problem), #160670, #162616 (merged; problem was lack
of symbols according to: #156082), and I'm sure others could point out
the libdb2/libdb3 and libpng2/libpng3 bug #s for the same issue in those

> >   - Implement versioned symbols
> >     - May cause binary compatibility issues
> >     - Doesn't follow LSB (I believe..)
> >     - Could be difficult to do correctly
> Very hard to implement and will result in non-trivial patches that
> upstream sources will probably never merge.

It's been done already in some places from my understanding
(libdb, libpng).  The fix being hard to implement doesn't somehow make
the problem go away.

> >   - Conflict between library versions
> >     - Wouldn't allow valid setups where the versions aren't linked into
> >       the same process
> >     - Lots of packages would end up uninstallable for certain library
> >       upgrades
> Those two reasons make it obvious we should not do that I think.

I agree, which is why I feel the right thing to do is get versioned
symbols in our libraries.

> >   At the moment I tend to think versioning the symbols is the 'right'
> >   thing to do and we should push to get upstream, other distros and LSB
> >   to do that too.  I don't think leaving things the way they are is
> >   acceptable.
> I challenge you to implement it for a few versions of a few different
> non-trivial libraries.

It's been done.  I don't doubt that it's difficult.

> I think a different solution: check for this problem when build a
> package and abort if you hit it. That is trivial to implement as
> a linda check or standalone tool you can call from debian/rules. In
> fact I think dpkg-scanlibs already does that.

I don't understand how this is supposted to work.  The ssh-krb5 
maintainer builds against libssl0.9.6 and uploads.  The openldap
maintainer builds ldap against 0.9.7 and uploads.  When someone tries to
use libnss-ldap or libpam-ldap with TLS support and ssh the ssh daemon
will segfault because of the 0.9.6 and 0.9.7 incompatibility.  Which
build is supposted to fail?  When ssh-krb5 was built initially it was
fine and everything was against 0.9.6.  Should, then, the openldap build
be aborted because ssh-krb5 linked against 0.9.6?  How would anyone ever
upgrade to 0.9.7?

The same problem exists with sendmail/libldap for libsasl7 vs. libsasl2.
sendmail is built against libsasl7 current because that's what libldap2
is against.  libsasl7 has problems though and libsasl2 is much better
and in the OpenLDAP update to 2.1 libldap2 will be compiled against
libsasl2.  Until the sendmail maintainer updates sendmail to build
against libsasl2 sendmail is going to crash for people using SASL for
sendmail and LDAP.  Thankfully the sendmail author and the OpenLDAP
folks are talking so that there should be a new version of sendmail very
shortly after OpenLDAP 2.1 goes in-- but the problem is still there and
I don't think is something you can easily detect when building the

Hopefully this problem will be something we watch out for during a
release at least so we can avoid it there, and maybe even develop
scripts and whatnot to keep the problem from happening in testing.  That
is, if it's even possible to have a script to check for this.


Attachment: pgputNYMXFXV5.pgp
Description: PGP signature

Reply to: