On Thu, Jan 03, 2002 at 05:48:53PM -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 03 Jan 2002, Ed Tomlinson wrote:
> > and have created one (See 127215). From my perspective the problem
> > seems to be the libpng3 changes the dependencies of qt2 and hense kde.
> > It seems the fix is not to revert/fix libpng but to fix the qt
> > dependencies however I get the impression that frustration is setting
> Yes. Actually, we have the same problem with every library that links with
> another library that is likely to be used by an app.
So the consensus is that the libpng/libqt2 fiasco is due to
having application A linked to shared libs L and M, while
libL is also linked to (a different version of) libM:
A -+-> libL ---> libM (version x)
`-> libM (version y)
where version x is not compatible with y, right?
> The best example is libdb*, but there are others. libtiff, libpng, libsasl,
Those would be examples of lib "M". Examples of lib "L" include the
infamous libqt2 and imlib1, so the issue is of interest to anyone who
uses KDE or GNOME.
So: how should we best handle a major version change in libM?
What do other "L"-type libraries do???
> You either make sure EVERYthing is linked against the same library versions
If we go this route, how do we gracefully handle a bump in
SONAME for libM? If an application is rebuilt with the new
version of libM, it will break. If libL is rebuilt with the
new version of libM, then all applications using libraries L
and M will break. Clearly libL and all the application packages
have to cooperate on the transition.
One idea is for libL to rebuild and declare versioned conflicts with
all its applications (that's what python recently did, isn't it?).
But that balloons the size of the conflicts list for a popular library
like libqt2. There must be a better way! (?)
> or you must tell any libraries that
> link to other libraries to use --symbolic dynamic linking,
That sounds plausible --- is it really as simple as this? The info
page for "gcc -symbolic" says "Only a few systems support this option."
Are all Debian systems covered?
> or you must use versioned symbols.
What does this mean? Would it apply to libL or to libM?
How would one implement this?
> We actually need a Debian-wide (well, probably a LSB-wide) fix for the
> problem. The same kind of breakage is expected to hit us again and again
> until we do that.
I agree. Suppose we limit our scope to Debian for the moment:
what is currently done by the other lib"L"-type libraries
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants