Hello,
I'd like to solicit opinions about what to do with
imlib-linked-against-libpng3.
Until August 2002, the Debian imlib packages were linked with libpng2.
Even after libpng3 was released in early 2002, imlib remained linked
with the older libpng2. This was done to retain the ABI of imlib,
especially the ABI of the GNOME version, gdk-imlib.
Imlib is more-or-less dormant upstream. However, in late August, I
was under the impression that upstream imlib was going to release a
new version (with new SONAME) that would be linked with libpng3. In
anticipation of that, I introduced imlib2/imlib-dev into Debian but
filed a Grave bug against it to keep it from moving to testing.
It is still not in testing.
I no longer believe that upstream will release any new versions of
imlib and I plan to ask that imlib2 be removed from the archive. I
don't want to change the current imlib1 linkage since imlib is pretty
much dormant and probably on its way out.
There are six packages currently linked against imlib2:
chinput
fnlib
kdegraphics
mgp
picturebook
wallp
I'm not sure whether they strictly require png3 or whether they could
simply be rebuilt with imlib1 and libpng2. In the past, however, some
KDE folks have explicitly requested imlib+png3.
What would be the best way to accomodate such a request? I can
imagine introducing a new package of imlib linked with libpng3. But
since it has to use the same SOVERSION as the current imlib1, it would
have to conflict with imlib1. Each individual admin could then choose
to use imlib+png2 or to use imlib+png3. However, each choice would
have its own set of incompatible programs so this option doesn't
appeal to me.
Another option is to drop the idea of imlib+png3. The six packages
mentioned above would then have to build either with png2 or somehow
incorporate imlib into their source build. For the maintainers of the
six packages: is that feasible?
-Steve
