Re: Neat gtk/gdk-imlib pain
Jason Gunthorpe <jgg@ualberta.ca> writes:
> On 1 Feb 1999, Jim Pick wrote:
>
> > Pretend that wmakerconf was linked with an imlib that used a
> > hypothetical libgtk1.1.20. So symbol gtkfoo from libgtk1.1.20 would
> > be referred to in wmakerconf like so:
> >
> > $ objdump --dynamic-syms /usr/X11R6/bin/wmakerconf | grep foo
> > 0003cea0 g DF .text 00000018 GTK_1.1.20 foo
> >
> > If a new imlib came along that was linked with the incompatible
> > libgtk1.1.21, the dynamic linker would examine both
> > /usr/lib/libgtk-1.1.so.20 and /usr/lib/libgtk-1.1.so.21 (based on
> > the soname search, like the present situation). However, instead of
> > binding to the first symbol it found, it would only bind to the foo
> > symbol in /usr/lib/libgtk-1.1.so.20
>
> Erm, but that doesn't make any sense in the context of glibc! glibc2.1 is
> NOT a unique soname but is simply a glibc2.0 with changes. Somehow the
> symbol versioning is used to tell '2.1 special' programs apart from '2.0
> special' programs and 'do the right thing' You don't need to have two
> libcs.
I believe that's the purpose for it in glibc. But it's a generic
facility that might be useful in other areas (like what I'm
suggesting).
> > I haven't tested that it would actually work this way, so take this
> > idea with a grain of salt.
>
> The trouble with that sort of simple view is that it assumes that you can
> freely mix the new features from a new libgtk with the old features from
> an old gtk in such a way as to not create caos and destruction, I don't
> think that can be done without alot of carefull planning.
That's true. When you try to run wmakerconf (compiled for slink) with
the new libraries in potato, you get chaos and destruction. We need
to figure out a way of avoiding that.
Using versioning, if the version mapping files were constructed with
care to reflect the changes in the API, there shouldn't be any
problems. If there are problems, then it's an upstream bug, and not a
packaging failure. I like that.
We are our own worst enemies - I don't know of any other OS in the
world that tries to maintain constant piece-by-piece upgradeability on
a continual basis -- like what we are doing in unstable. For example,
Red Hat is on a 4 month release cycle. Mainstream commercial OS's
take several years between releases. These other OS's just don't have
the same issues, because they have enough time between releases to get
all their programs and libraries in sync. And they upgrade everything
in one big batch. Nobody else is crazy enough to try to do what we
are doing.
The way we manage libraries with dpkg starts to break down after we
get applications that use close to thirty different libraries. It's
do-able, but trying to maintain compatibility when the libraries are
being updated continually day-by-day isn't easy, and probably has
never been attempted before. We might have to invent some new
techniques or use some new technology to make it work.
Cheers,
- Jim
Reply to: