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

imlib and libpng


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.

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,

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: