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

Re: GNOME 1 ABI involving libpng



On Thu, Aug 29, 2002 at 02:15:30AM +0900, Akira TAGOH wrote:
> Notes that libgtk2.0-0png3 didn't breaks ABI. if that
> application links gtk+2.0 and *libpng2* at the same time,
> basically you are right. but that application needed to be
> rebuilt agaist libpng3 anyway since gtk+2.0 linked against
> libpng3. it's not related -dev's Depends, because we have
> Build-Depends to solve this problem.

I know this is mostly done and dusted now, but it really upsets me that
the library was re-named when actually there were only three packages in
unstable which linked to both libgtk2.0 as well as libpng2. They were
gimp1.3, celestia, and metatheme. Those were the only three that could
have broken. The correct thing to do would've been to just re-compile
against libpng3, and declare a conflict with those three packages <= the
version in unstable, and have them rebuilt.

In fact, you can now revert the library name change safely, to allow
smooth upgrades from woody. Change the package back to libgtk2.0-0,
change shlibs, and provide a libgtk2.0-0png3 stub package that depends
on libgtk2.0-0. You would also need to have versioned <= conflicts with
those packages in woody that depend on libgtk2.0 and libpng3 at the same
time. You could drop the libgtk2.0-0png3 from sid after everything had
compiled back to libgtk2.0, and it need never show up in a release.

> Actually if that application didn't links libpng directly,
> it's unnecessary libpng3-dev to *use* libgtk2.0-dev.

This is right, linking to libgtk2.0-dev, an application should only see
the libgtk-pixbuf API if it wants to do things with images. It doesn't
currently cause linking with libpng3, so a dep of libgtk2.0-dev on
libpng3-dev is not necessary.

> GLib's API refference isn't enough for you?
> file:///usr/share/doc/libglib2.0-doc/glib/glib-dynamic-loading-of-modules.html

What he meant is that it's not documented whether calling g_module_open
will load shared libraries into the global namespace, or their own. If
something calls g_module_open and then tries to access the shared 
library's symbols outside the module it loaded, that is depending on
undocumented behaviour - assuming RTLD_GLOBAL was being used.

> Akira TAGOH  : tagoh@gnome.gr.jp  / Japan GNOME Users Group
> at@gclab.org : tagoh@gnome-db.org / GNOME-DB Project
>              : tagoh@redhat.com   / Red Hat, Inc.
>              : tagoh@debian.org   / Debian Project

Regards,
Rob



Reply to: