On Fri, 07 Mar 2003, Wichert Akkerman 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'.
We have been very bad on that regard. Certain... not-so-nice measures would have to be taken to keep up with the 'do not do that' solution. I consider that non-workable for core libraries (SASL, LDAP, glibc/nss modules, libX* and unfortunately, part of the kde and gnome bloat). As an example: for SASL (which currently causes breakage encompassing LDAP (and through it, glibc nss modules), we would have to force-feed upstream a SASL2 enabled source of postfix and sendmail, for example. We would also have to drop our old openldap 2.0 and somehow get 2.1 ready. > > - Implement versioned symbols > > - May cause binary compatibility issues > > - Doesn't follow LSB (I believe..) > > - Could be difficult to do correctly After we fix the @[EMAIL PROTECTED] cretin problems with the dynamic loader adding static crap to libraries in certain archs [that must not be versioned], it is actually trivial to do correctly, GIVEN a proper build environment (i.e. not massively braindamaged makefiles, etc). > Very hard to implement and will result in non-trivial patches that > upstream sources will probably never merge. Indeed. But it is actually useful for Solaris as well, so you might find some of upstream quite willing to take the patches. We already do so for libdb, and upstream for libsasl already said they would accept patches that did it right. It is difficult to know how many would be willing, if there is a hard enough shove (with ready-to-apply patches, obviously). > > - 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. It is actually not doable. Libraries conflict only inside a process boundary (unless they have been extremely badly designed and have an external dependency on a file or something like that), so we must allow conflicting libraries installed in the system. > I challenge you to implement it for a few versions of a few different > non-trivial libraries. We just need it for libraries that are themselves linked by other libraries, and that change too much. E.g. libz doesn't need it (thank god!), but SASL and openldap most definately do, and glibc and libdb already have it. > 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 Won't work 100% of the time. dlopen makes this also a runtime problem. > a linda check or standalone tool you can call from debian/rules. In > fact I think dpkg-scanlibs already does that. Well, either linda or lintian is indeed trapping illegal linkage of two different versions of libraries in the same binary. But this catches only a part of the problem, and the easy one to fix, at that :( -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
