Re: Neat gtk/gdk-imlib pain
On 1 Feb 1999, Jim Pick wrote:
> > libgdk-imlib1 in slink did not seem to depend on any glib, in potato it
> > depends on a new and incompatible glib from potato BUT the soname was not
> > changed. So the instant you install this new libgdk-imlib1 ~40 apps from
> > slink silently stop working!
>
> Actually, if you look again, you will see that the soname is not the
> problem.
Read the libtool thread. What has been done here is to recompile a library
against a different set of libraries in an incompatible way without
changing the soname
> In fact, imlib is only being pulled in once. The problem is that glib is
> being pulled in twice (from libraries/binaries that were linked with
The library that does this is imlib according to my investigation.
> The is a clean solution for this BTW - in glibc 2.1, H.J. Lu has added
> support for symbol versioning.
I don't know much about the symbol versioning but I highly doubt that
using glibc2.1 will have any effect on this problem with gtk. My
understanding is that the library author will have to take special steps
to make versioned symbols through some magic means..
> incompatible base library in potato than what is in slink. Basically,
> anything that depends on the 1.1.x (unstable) versions of glib and
> gtk, and imlib too.
Yep
> I'm not sure that it is worth the effort. We shouldn't be
> guaranteeing that applications that depend upon unstable libraries
> (ie. libglib1.1.x, libglib1.1.x, etc.) will be easily upgradeable.
Isn't the slink imlib/gtk1 'stable'? I really don't follow their
development. If you accept that gtk 1.0.6-2 is a stable library then you
have to take steps to ensure that installing the unstable libraries do
not kill the system, it is the only nice thing to do :<
> going to break - perhaps we shouldn't be releasing things that use
> libglib1.1.x and libgkt1.1.x - which are part of the development
> branch.
That is probably a sane idea in of itself.
> > Oh, the other alternative would be to make gdk-imlib1 in potato conflict
> > with the old gdk that it used to use. That might solve this particular
> > instance.
>
> I don't like conflicts. Renaming the library makes more sense. But
> it's going to be a lot easier to just ignore the problem - and
> convince people not to mix slink and potato. The problem is only
> going to get worse in a few weeks when we go to glibc2.1 anyways.
Well do one or the other, this 'silent breakage' is really nasty and will
probably generate alot of confused users (already has actually, people
complain to me that their old gtk apps die when they installed
gnome-apt!). For the moment I suggest the conflicts because it can
easially be done..
I don't see how glibc2.1 wille effect things at all, it is fully
compatible with 2.0 there will be no pain aside from any intrinsic
buggyness it might have.
Jason
Reply to: