Re: Great news on the GNOME 1.4 front...
Hello,
On Wed, 28 Aug 2002, Robert McQueen writes:
> Incoming now has the packages imlib1, imlib1-dev, gdk-imlib1 and
> gdk-imlib1-dev. These link against libpng2 like the old ones did
> before our imlib maintainer made the unilateral change to up the
> soversion to create imlib1 linked against libpng3, which he called
> imlib2 which exists nowhere else on the planet in any distro - do
> not confuse it with libimlib2 which is a totally different source
> package.
>
> This means GNOME 1.4 libs can have their build deps changed to use
> the new gdk-imlib1-dev, and need not mention or concern themselves
> with any libpng*-dev packages. Then they can be rebuilt and it will
> all fall back into place, and we will once more be ABI compatible
> with our existing releases and everybody else - we should ignore
> imlib2 as a strange Debian curiosa and not compile anything against
> it.
Very droll.
I understand that you are frustrated with packages suddenly building
incorrectly. If you need a whipping boy, then fine, I'll be your
scapegoat.
However, anyone who thinks this was a unilateral action on my part
hasn't been paying attention. I posted to this list my plans for
imlib and png in mid-July:
http://lists.debian.org/debian-gtk-gnome/2002/debian-gtk-gnome-200207/msg00180.html
None of the current critics chose to raise their concerns at that
time. Around the end of July, I sent an email to maintainers of
packages that build-depend on both imlib|gdk-imlib and libpng2,
advising them of the proposed change to imlib and asking for
reactions. I received none.
So I made the change to imlib (Aug 11), and emailed to all developers
of *all* packages that build-depend on imlib|gdk-imlib. In this
email, I specifically noted:
* With this upload, the imlib1 and gdk-imlib1 packages become
unbuildable. I expect that all code that uses imlib can simply
recompile with the newer version. If this proves not to be the
case, let me know and I'll reintroduce imlib1 and/or gdk-imlib1
compiled with libpng2.
* A package that requires both gdk-imlib and libpng, on the other hand
may build but fail at runtime, if built with libpng2. This is
because gdk-imlib employs libpng3 via a dlopened() module.
* If you accidentally link an application with imlib and libpng2, the
application may behave in unpredictible ways, possibly crashing,
possibly emitting warnings similar to the following:
libpng warning: Application was compiled with png.h from libpng-1.2.1
libpng warning: Application is running with png.c from libpng-1.0.12
libpng error: Incompatible libpng version in application and library
It seems to me that no packager of a Gnome 1 app should be surprised
by a bug report about libpng. I don't understand all the heat
generated in the bug reports and on the list. All you had to do is
ask for imlib1-linked-with-png2 (Ryan Murray asked) and it was uploaded.
Why did imlib change?
---------------------
For plain imlib (libImlib), I needed to link with libpng3 to satisfy
the KDE folks. This library does NOT use modules, so changing the
linkage requires changing SONAME. This change has been coordinated
with upstream, despite the fact that the new source package is yet to
be released. Redhat has made the change in their "Rawhide" beta
packages. I did second-guess the upstream choice of soname version,
so Robert was right about libImlib.so.2 being a Debian curiousa. I've
filed RC bugs against that package to prevent it getting into testing.
As soon as the upstream release comes out, I'll rebuild it with the
correct soname (libImlib.so.11) and all will be well.
With respect to gdk-imlib and libpng, I have no agenda. If it is the
consensus of the list, I'm content to leave gdk-imlib1 with libpng2.
Note that *only* gdk-imlib is part of Gnome; imlib (libImlib) is not.
Should GNOME 1.4 use libpng2?
-----------------------------
I have been operating under the assumption that now is a good time to
drop libpng2. We've got quite some time before any plausible freeze
of sarge. However, once the change to gdk-imlib was made several
folks howled about "the Gnome 1.4 ABI".
That's a fair concern. Although I couldn't find any document specifying
it, it would be fair to say that the Gnome 1 ABI consists of the set of
gnome libraries. But what about the libraries they link against, e.g.
libtff, libpng, etc? Do they constitute part of the Gnome ABI?
If they do constitue part of the Gnome 1.4 ABI, then there must be a
document somewhere listing the version of each secondary library to
use. I am not aware of such a list. Indeed, about a year ago,
Debian's imlib switched from libungif3g to libungif4g, with no
protest. So I have to suppose that the versions of secondary libs do
NOT form part of the ABI.
Of course, libpng is special, because (1) at least two Gnome
libraries, gdk-imlib and gdk-pixbuf both dlopen it in their respective
helper modules, and (2) mixing libpng versions cause the application
to fail badly. Clearly, changing libpng can only be possible if the
maintainers cooperate.
[I now suspect that it is only because no other Gnome lib uses
libungif that changing gdk-imlib was possible.]
I personally see no reason to keep going with libpng2. The usual
argument of binary compatibility with other distributions is nice in
theory. In practice, the version of libpng used by gdk-imlib
probably isn't (or shouldn't be) part of this ABI.
Redhat has already changed imlib to use libpng3, removing it from the
global namespace. To my mind, that is already a change in the ABI of
imlib, albeit a very subtle one. [I considered doing this, but was
planning to change the soname version of gdk-imlib anyway, due to this
subtle modification of the imlib ABI.] If folks do want to drop png2
but are attached to the Gnome 1.4 SONAMES, Redhat's method is probably
the best compromise.
The status quo of png2 only is possible, and the easiest choice. The
only drawback is that you annoy anyone who is developing for both
Gnome 1 and Gnome 2, due to libpng?-dev conflict.
The third choice is to introduce new SOVERSIONs for both gdk-imlib and
gdk-pixbuf --- in coordination with upstream, of course.
So, which shall it be?
Constructive criticism welcome, flames ignored,
-Steve
Reply to: