Hi, Back in January, libpng version 3 was released. This PNG library happens to be linked into several libraries (e.g. imlib and qt2). It is also linked into many applications which also link to imlib or qt2. Such an application will fail if the PNG library version it links with is different than the PNG library that imlib or qt2 links with.
A fair bit of discussion was generated at the time, e.g. http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg00002.html The only consensus that emerged is: if imlib changed from PNG2 to PNG3, then the imlib SONAME should change. In the interests of the woody freeze, nothing has happened yet: imlib, and anything that links to it, is using libpng2. However, the KDE folks are increasingly impatient to use imlib with png3. It's time to update imlib, so I'm looking for ideas. Given that the SONAME for imlib will change, the two versions of imlib will be able to be installed in parallel, and so no existing packages will break. I'm not sure what to do about the -dev package, though. If I just switch it to png3, then almost surely some packages will fail to build or, once built, fail to run. I guess I could prevent them from building by declaring the new imlib-dev to conflict with libpng2-dev. If that happens, the packages in question will not build until their maintainer fixes up the build-deps. In unstable/main, of the 129+2 source packages (main+contrib) that build-depend on imlib (there are no such packages in non-free nor non-us), I find just 18 that also build-depend on libpng2. At first blush, it seems that the number of affected packages is rather small. On the other hand, among the packages that link with imlib are some libraries. It is conceivable that one of THOSE may be used along with libpng2 in some other binary. While that 18 is only a lower bound of the number of affected packages, it seems small enough that my plan (tentatively) is: 1. Notify the maintainers of these 18, then 2. upload the changed imlib packages (the -dev packages conflicting with libpng2-dev). If porting a package to libpng3 proves infeasible, I'm willing to upload an "imlib+png2-dev" package. About the new SONAME for imlib. It would be nice if we had cooperation across distributions about this. I've emailed upstream a few times over the the last month or two about picking a standard soname, but have heard nothing back. For their "rawhide", RedHat went ahead and linked in libpng3 *without* changing the SONAME. So I think we can kiss cross-distribution compatibility goodbye. My feeling at the moment is to just change the current "libImlib.so.1" to "libImlib.so.1.1" (or "libImlib.so.1.png3" maybe). If there is a policy or precedent for this, I'd be happy to hear about it. I welcome any feedback, -Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
