Re: KDE 3 / KDE 4 compatibility
On Mittwoch, 3. September 2003 01:46, Ben Burton wrote: > > 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) > > I don't thinking supporting simultaneous koffice versions is something we > need to be worried about. Arts and kdelibs are modules that everything > else depends on, and so it is desirable to support multiple versions of > them. KOffice on the other hand is basically a set of applications, and > so I see no specific reason for users to want older versions installed > (at least any more than users might want older versions of vim, xfig, > whatever installed). Right. We're not yet at a stage where the koffice libs are used by third party programs. Ralf > > Ben. -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgpukFtISRN1t.pgp Description: signature
Re: KDE 3 / KDE 4 compatibility
> 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) I don't thinking supporting simultaneous koffice versions is something we need to be worried about. Arts and kdelibs are modules that everything else depends on, and so it is desirable to support multiple versions of them. KOffice on the other hand is basically a set of applications, and so I see no specific reason for users to want older versions installed (at least any more than users might want older versions of vim, xfig, whatever installed). Ben.
Re: KDE 3 / KDE 4 compatibility
On Tue, Sep 02, 2003 at 10:29:34PM +0200, Ralf Nolden wrote: Content-Description: signed data > On Dienstag, 2. September 2003 19:27, Chris Cheney wrote: > > > 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. :) > No, we have to sort out the mess for KDE 3.2. KDE 4 will introduce way too > many other problems, beleive me :-) This is why I'm bugging everyone right > now to fix the issues since the meeting last week. I was under the impression that no binary incompatible changes could happen before KDE 4? > > > 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. > This has been fixed - coolo did a wrong commit and cleaned it up, dirk fixed > it a second time. Now the kaddprinterwizard program gets build again plus the > kaddprinterwizard.so/.la get installed in /usr/lib/kde3. > > The question is just why /usr/lib/kde3/kprinterwizard.so/.la is in > kdelibs-bin; it should be in kdelibs4. In KDE 3.1 kaddprinterwizard appears to be a binary/library speed hack. It is similiar to the libkdeinit_* binaries in KDE 3.2. Was the binary not supposed to really be built, if so we could remove that in BRANCH and then move the so/la to /usr/lib/kde3? There is no /usr/lib/kde3/kprinterwizard.so/.la in KDE 3.1, perhaps you typo'd? > I found another outstanding one, knotify.so/.la. knotify, at least in KDE 3.1, is also another one of the binary/library speed hacks eg libkdeinit_* > > > - 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. > > Can you get into contact with Stefan Westerfeld and Stephan Kulow please to > resolve those issues ? If they can't be solved then the work on KDE 3.2 is > more or less bogus I think :-) if there isn't a different way to solve the > issues. Ok, will try to convince them to fix that issue... Thanks, Chris Side note: I wonder if the dists installing stuff into /opt could be declared non LSB conforming... /opt is reserved for 3rd party apps only, similiar to how /usr/local is only for local admin stuff. (This isn't a Debian only decision...)
Re: KDE 3 / KDE 4 compatibility
On Dienstag, 2. September 2003 19:27, Chris Cheney wrote: > 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. :) No, we have to sort out the mess for KDE 3.2. KDE 4 will introduce way too many other problems, beleive me :-) This is why I'm bugging everyone right now to fix the issues since the meeting last week. > > 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 ... No, this is all HEAD, not the branch. I moved that already today. > > > 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. This has been fixed - coolo did a wrong commit and cleaned it up, dirk fixed it a second time. Now the kaddprinterwizard program gets build again plus the kaddprinterwizard.so/.la get installed in /usr/lib/kde3. The question is just why /usr/lib/kde3/kprinterwizard.so/.la is in kdelibs-bin; it should be in kdelibs4. I found another outstanding one, knotify.so/.la. > > > > 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 ? No, you can't fix that for KDE 3.1 anymore. This is too late; you'll just introduce new bugs when trying to backport. This will unfortunately only be reasonable in HEAD, so - also unfortunately - we can't make sarge already KDE 4 compatible. This has to be done when KDE 3.2 enters unstable, but that again means for a sarge user if he installs KDE 3.2 kdelibs for sarge he'll be able to use all KDE 3 programs in sarge even with KDE 4 (that's the goal at least). > 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. Yes, and KDE 3.2 before. That means with sid we can introduce a KDE 3.x kdelibs set that lets the user use KDE 3 apps from sarge on sid (or, to be more precise, lets the packagers and developers some more time when a program isn't available as a KDE 4 program; sid can easily ship the KDE 3 version unlike sarge which had to have all KDE 2.x programs removed/upgraded to KDE 3). > > 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? No, doesn't. The sover will be bumped on KDE 4 no matter what because Qt 4 will bump the sover as well. This mistake happened to us from KDE 2 -> KDE 3 with qt-2 to qt-3 where KDE didn't bump the sover cleanly. > > - 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. Can you get into contact with Stefan Westerfeld and Stephan Kulow please to resolve those issues ? If they can't be solved then the work on KDE 3.2 is more or less bogus I think :-) if there isn't a different way to solve the issues. > 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. Yes. As we're having detailed installation lists we need to go through them and fix those issues now or at least in the coming one to two month, otherwise we'll carry that burden over into KDE 3.2 where the master plan of having compatibility between KDE 3 apps and a KDE 4 desktop won't be possible on debian again. Ralf > > Chris -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgp5zDhrORnJx.pgp Description: signature
Re: KDE 3 / KDE 4 compatibility
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)
KDE 3 / KDE 4 compatibility
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. 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. 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. 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. 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) Ralf -- We're not a company, we just produce better code at less costs. Ralf Nolden [EMAIL PROTECTED] The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org pgpafeKc3USKd.pgp Description: signature
