On Tue, Sep 02, 2003 at 04:21:55PM +0200, Ralf Nolden wrote: Content-Description: signed data > Hi guys, > > I'd like to sum up some of my thoughts on how things will proceed with KDE > into next year and how we can at least try to get things as easy as possible > for the users. > > Library mess and the prefix > > The main problem as we all know on debian compared to e.g. SuSE is that it > uses /usr as the prefix for all KDE versions. That per se wouldn't be a > problem if KDE wouldn't cause problems. For most developers it isn't an issue > at all because they just think, use another prefix and be done. SuSE e.g. > used > > /opt/kde for KDE 1 > /opt/kde2 for KDE 2 > /opt/kde3 for KDE 3 > > and will probably use /opt/kde4 for KDE 4. This avoids collisions with > packages totally but this doesn't make KDE better in terms of usage with > systems that use a single prefix. > > The result was that during the KDE 2 to KDE 3 move, KDE didn't take care > enough of libraries and kde modules in terms of major numbers for libraries > and the installation location of modules. One reason for this has certainly > been that sometimes a library can be a module at the same time. This requires > installing the library itself plus the symlinks up to the major version plus > the .la file so it gets accessible via dlopen as a module. > > When a major version increas happens, the library packages will collide in > the .la file necessarily. We've tried to reduce this and to clean up KDE 3 to > some extend but this hasn't been completed yet. Last week at the developer > conference when we had Matthias Ettrich's talk about Qt 4 coming next year, > it got obvious that KDE will switch to Qt 4 as soon as possible for the > project. That means that KDE 3.2 will probably be the last release that will > stay compatible with KDE 3 and the next major release will be KDE 4; there > won't be too much time to make a KDE 3.3 release. Once KDE 4 is being worked on upstream we will need to try to get all the rest of the mess cleaned up. Hopefully we will have time. :) > For those who after the release of sarge will want to continue using sarge > with all of it's KDE programs that rely on kdelibs4 (from KDE 3.x) this will > turn out to be a problem as soon as they want to use KDE 4 - the same > nightmare will happen to those programs like with KDE 2 programs as soon as > KDE 3 got installed on woody. > > The solution is therefore to make sure that libs that are modules as well > become a separate file as a module. I talked to Dirk and this has already > happened to the annoying libkhtml, effectively we now have > > /usr/lib/libkhtml.so.* > /usr/lib/kde3/khtmlpart.so/.la > > This allows us to move the libkhtml.la file from the kdelibs4 package to the > kdelibs4-dev package. For all libkdeinit_ libraries Dirk has told me that .so > and .la files can safely be moved to the -dev package as well. These have happened on KDE 3.1.x ? Also on KDE 3.2 the last time I built it, last week, it did not have versioned SO for the libkdeinit_ binaries, so all that was provided was .so/.la ... > The only outstanding issues now are > > libkdeprint_mananagement.la (lib and module, needs split-up like khmtl) > /usr/lib/kaddprinterwizard.so/.la which should be a module and is installed at > the wrong location. > > I already have the above issues fixed and will commit updated install files > and a changed control file that introduces a conflict for kdelibs4-dev with > kdelibs4 (<< 4:3.1.90). > > On the libkdeprint_management and kaddprinterwizard I'm still trying to get > those issues fixed. Do the above need to be fixed for KDE 3.1.x ? > Effectively this will mean that a user who will have sarge installed can: > > - upgrade to KDE 3.2 once released > - upgrade to KDE 4 once he has kdelibs4_3.2.0 or higher installed that will > bring a non-conflict against kdelibs5 for KDE 4 for kdelibs4. > > For unstable, this will mean that when KDE 3.2 gets in we don't have to > conflict to KDE 4 for the applications that are based on KDE 3 libs but can > be installed at the same time; so the user can have kdelibs4 and kdelibs5 > installed. The user will need to be able to upgrade from KDE 3.1.x -> KDE 4.x since this is probably how it will actually happen in Debian dist upgrades... KDE 3.2 won't make it into sarge barring some major problem with sarge release. However, KDE 4 very well might make it into sarge+1. Also, to allow KDE 3 and KDE 4 to be coinstallable would require splitting the various lib packages into library per package (I think?), since each library doesn't necessarily bump sover, right? > I'm not yet sure how this will work out on the kdelibs-bin package yet; I hope > that won't have any influence. > > What I would like to know is now (probably calc and bab can say somethng > there): > > - do we have the same issues with arts and koffice and kdebase ? (I think I > remember something like this darkly) Yes, there are similiar problems with arts... arts doesn't have a fscking module dir at all, it puts all its modules into /usr/lib. Also, the /usr/lib/mcop dir isn't versioned so may cause additional difficulties, but I'm not sure. Also, I don't know if they have all been cleaned up on KDE 3.2 but various other official kde apps stuck kparts into /usr/lib, that definitely needs to be verified/fixed before KDE 3.2/4 release. Chris
Attachment:
pgp1QRfUZl5Ai.pgp
Description: PGP signature