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

Re: Neat gtk/gdk-imlib pain



Jason Gunthorpe <jgg@ualberta.ca> writes:

> If glib, gtk, gnome, imlib, etc used versioned symbols then yes you
> -might- advoid this.
> 
> -HOWEVER- my understanding how how versioned symbols would need to be
> implemented would make this pretty much impossible for a large portion of
> the libraries that compose gnome. (ie you have to provide the orignal
> symbol and somehow interweave it into the new library structure)

I'm not sure if you need to provide the original symbol - I think
ld.so is smart enough to pull the appropriate symbols from the
appropriate libraries (providing their symbol maps were set up
correctly).  There's at least 50 pages of documentation explaining all
the various details - I don't pretend to understand it.  I think it's
one of those things you can only figure out by doing it.
 
> > Anyways, the wmakerconf problem can be fixed for potato by recompiling
> > wmakerconf for potato with the proper libraries (and recompiling it
> > every time one of it's dependent libraries breaks compatibility, which
> > happens almost weekly with gtk/glib 1.1.x).
> 
> There are currently 72 things that link against imlib. I suspect that
> about half were linked with the 'old' imlib and half with the 'new' imlib.

That's to be expected.  The current situation demands that all those
apps should be rebuilt everytime gtk or glib breaks compatibility.

Most of the time, applications aren't affected by the particular
routines that broke compatibility, so they don't fail - but that's
just dumb luck.

> So no matter what system you have half your apps will magically break
> without warning or explanation. To make things worse the packages using
> the 'new' imlib do not have a versioned dependency on the new imlib
> (though it got installed so something must..)

If we do conflicts, then apps won't break - but you'll usually have to
de-install half of them anytime you want to use one that uses a newer,
incompatible library from out of unstable.

If we change the SONAME, apps won't break either, and upgrades will be
easy - but we'll end up with zillions of libraries.  And you can kiss
binary compatibility between distributions goodbye because of the
different SONAMEs (perhaps not a big deal, since we are dealing with
libraries that are under development anyways).  I'll have to change
the SONAME on libgnome almost weekly.

If we do nothing, then people using unstable will suffer from broken
applications.  It's less work for the maintainers, who are already
overloaded.

I hope versioned symbols in glibc 2.1 will stop the insanity.  But I'm
not sure.

Cheers,

 - Jim


Reply to: