* 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 libraries. > > - 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 package. 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. Stephen
Attachment:
pgputNYMXFXV5.pgp
Description: PGP signature