On Tuesday 26 April 2005 10:31, Steve Langasek wrote: > On Tue, Apr 26, 2005 at 09:15:09AM +0200, Matthias Klose wrote: > > A proposal for a simplification, which reduces/avoids the renaming of > > the KDE packages. All KDE packages depend directly or indirectly on > > libqt3, so it is enough to rename the packages libqt3c102 to libqt3 > > and libqt3c102-mt to libqt3-mt and add a conflict with th old name. > > This way, you cannot install qt3 dependent packages which are built > > with different compiler versions. This avoids renaming about 100 out > > of 400 packages containing libraries. > > Ok, I'm now able to formulate the rationale for the question I had earlier > about this. Are we sure that all of these KDE apps *need* to depend on > libqt3c102-mt, or do they just do so because of classic libtool/pkg-config > bugs? If any one of these KDE apps is linked against libqt3c102-mt solely > due to historical breakage, we have this scenario: > > Random KDE app, "kohlrabi", gets built with fixed libtool prior to > transition, loses the Qt dep but retains the kdelibs4 dep As soon as one uses a single KDE widget QT in pulled in via inheritance. There are only libkjs.so (_javascript_) and libkjava.so (Java IF to KDEs html engine) and libkdefakes.so (only some portability funtions) that do not link to libqt-mt.so. So only problem I can see is a non GUI application usings KDEs _javascript_ engine. Don't now is something like that exists. > > libqt3c102-mt goes through ABI transition, is renamed libqt3, conflicts with > old libqt3c102-mt package > > kdelibs4 is rebuilt against libqt3 and the new ABI, becomes installable > again > > kohlrabi, which depends on kdelibs4, remains installable but is broken > > > And as it turns out, for a current example of "kohlrabi", see kdoomsday or > amarok... kdoomsday: includes qt headers and .so depends on libqt-mt.so.3. I guess /usr/lib/kde3/*.so is not searched for shlib dependencies. amarok: 1.2.3-1 depends on qt3c102-mt (>= 3:3.3.3) and amarok is full of qt and kde stuff. > > I don't know how deep the library dependency chain is on KDE, but it's > entirely possible that this problem applies all the way up. > > -- > Steve Langasek > postmodern programmer -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] |
- Re: C++ ABI transition for etch Achim Bohnet
- Re: C++ ABI transition for etch Steve Langasek
- Re: C++ ABI transition for etch Brian Nelson
- Re: C++ ABI transition for etch GOTO Masanori