I have put new libpng packages online at http://people.debian.org/~joss/packages/ and I would appreciate some comments and testing with them. *DO NOT BUILD OFFICIAL PACKAGES WITH THESE PACKAGES INSTALLED* These packages try to work around the (not so hard, but likely to increase) libpng mess using versioned symbols, but without breaking compatibility with other distributions and older versions of Debian. The idea is quite simple : not enable versioned symbols when linking software by default. What *might* (see below) be broken by these packages : - running software built with Debian's libpng10/libpng2 on other systems (this may concern software linked with gdk-imlib1, see below) ; - running Debian's libraries using libpng, taken from our .deb's, on other systems. What we can gain : - software linking to both libpng10 and libpng12 can work (I'm only aware of the plplot case) ; - we can finally migrate some libraries that use libpng10 and were held back by other libraries to libpng12 ; - we prepare the next upstream major version bump instead of getting in the same mess with more and more headaches every time. How this is/will/would be achieved : - libpng10 is built with versioned symbols ; - 2 versions of libpng12 are built with the same SONAME ; the library in libpng12-0 uses versioned symbols, but libpng12.so (or libpng.so) in libpng12-dev is the other version, built without versioned symbols. The symlink to the versioned-symbols enabled library is libpng12-versioned.so (or libpng-versioned.so) ; - our binary packages can then continue to link with -lpng ; they won't require versioned symbols, but will run with the library having them, which is not a problem ; - our library packages will have to link with -lpng-versioned to get the functionality. Random thoughts : - Gdk-imlib1 doesn't link directly with libpng, but rather lets the final application do it (against libpng10). Applications will still have to do that against libpng10, but will be able to link with other libraries using libpng12 (e.g. SDL) at the same time. - This won't solve the case of the package foo linking with libpng and with libbar, itself linking with libpng, as long as foo is not linked to libpng-versioned itself. I suggest we leave the decision to use versioned symbols or not to the package maintainer. - Software linked with the versioned-symbols enabled library seem to function properly even when the library on the system doesn't have those. The dynamic linker only issues a warning. Could people with other distributions test whether this is always the case ? If there are no problems of binary interoperability with other distributions, we could enable versioned symbols by default. - The next major upstream version is probably not likely to get out soon, so we can take all our time to do that transition smoothly, rebuilding the libraries in a matter of months (or even more than a year). Of course, I won't upload these packages without a clear consensus this will lead to a better situation than the current one. The major drawback of changing all library packages should be taken into consideration. *DO NOT BUILD OFFICIAL PACKAGES WITH THESE PACKAGES INSTALLED* Regards, -- .''`. Josselin Mouette /\./\ : :' : josselin.mouette@ens-lyon.org `. `' joss@debian.org `- Debian GNU/Linux -- The power of freedom
Attachment:
signature.asc
Description: PGP signature