[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
nolden@kde.org

The K Desktop Environment       The KDevelop Project
http://www.kde.org              http://www.kdevelop.org

Attachment: pgpIfZqKRKqDK.pgp
Description: signature


Reply to: