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

Re: Bug#155689: libgtk2.0-png3: -png3 should Provides: libgtk2.0-0

>>>>> On 09 Aug 2002 22:08:21 -0400,
>>>>> "JD" == Joe Drew <hoserhead@woot.net> wrote:

JD> I would be satisfied if a new release of libgtk2.0 was released
JD> upstream, *requiring* libpng3, and incrementing the soname, so we could
JD> have libgtk2.0-0 linked against libpng2 and libgtk2.0-1 linked against
JD> libpng3. Is this a possibility? (It's only worthwhile if the new version
JD> of gtk *requires* libpng3.)

I've forwarded this mail to Owen Taylor. and I got an answer
as an attached mail.

--
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
--- Begin Message --- 
No, we aren't going to change the soname of GTK+, for any reasons,
for the next 3-4 years.

gdk-pixbuf intentionally does not link directly against libpng
and does not include libpng in the output of:

 pkg-config --libs gdk-pixbuf-2.0

So that if an app links only against GTK+, then there is no
problem when the version of libpng changes.

As for the question of apps that link against GTK+-2.0 and 
against libpng-1.0 directly ... it's very hard to handle that; 
this is why changing sonames is a bad thing. (If you changed the
GTK+ soname, you would generate many more problems like that.)

Possible solutions:

a) Install two copies of the gdk-pixbuf modules, and use a wrapper 
  script for the application that sets GDK_PIXBUF_MODULEDIR.

b) Hack the GTK+-2.0 gdk-pixbuf not to load the image modules
   with RTLD_GLOBAL. (This is what we did for gdk-pixbuf-0.1x
   for Red Hat; see the patch in our package.)

I generally wouldn't consider it worth the effort unless you
have actual problems.

Regards,
                                        Owen

(Feel free to forward)

--- End Message ---
Reply to: