[PyKDE] 10.0 official rpms for PyKDE

[Jim Bublitz]

> Same with the "unofficial" SUSE RPMs.

> My target is to build a set of upgraded "Qt/KDE Python tools" including
> Python 2.3.4, SIP 4.0, the latest stable PyQt, PyKDE 3.11, and Eric 3.4.2.

> The problem is that during the last couple of weeks there was not a
> single day when all of the parts of the whole were stable at the same
> time ;-)

I believe you'll find that mentioned in the Book of Revelations as sign of the 
end of the world. :)

> It would be great if we could get the "Python tools" in sync with the
> next major KDE release (3.3), i.e. at the time KDE is released the
> upgreaded Python bindings are available, too ...

KDE 3.2.3 is due in the next few weeks (last time I looked at the KDE release 
schedule), and the next PyKDE release should be ready very shortly after 
that.  Phil has just released sip 3.10.2 (which the next PyKDE release will 
require) and hopefully the last sip4 rc (which PyKDE should work with), so 
sip 4.0 should be fairly close. Phil is also planning a PyQt update shortly. 
So everything should be in sync then.

From what I've looked at, KDE 3.3 won't change a lot in kdelibs (which is all 
PyKDE cares about), and I'm planning on tracking the betas and rc releases. 
If the last kdelibs 3.3rc is binary compatible with the final release, I 
could have PyKDE complete *before* the final. But then in theory, 3.3 is 
supposed to be binary compatible with 3.2, I believe.

The problem in doing that is that the final rpms from SuSE, Mankdrake and 
whatever RH/Fedora is doing now are never compatible with "official" KDE 
source code (I get the source either from kde.org or uk.kde.org) - eg 
KFileShare::setShared on SuSE 3.1.x later rpm releases, similar stuff on Mdk 
or RH, QXEmbed with some distros, etc. It only takes one modified or deleted 
method to make PyKDE essentially unusable - PyKDE binds nearly every method 
in the kdelibs modules it supports, which most apps don't do. 

That being the case, I'd be shooting myself in the foot by doing a release 
ahead of the official KDE 3.3 rpms and not testing against those. Usually, I 
only build against the latest KDE on SuSE, but test earlier versions against 
Mdk and RH. 

I have enough problems when I do test (eg, the current problems with kdeui not 
finding kdefx on Mdk 10.0, which doesn't happen on Mdk 9.x, any SuSE after 
8.1 or RH9.x). 

With PyKDE now up-to-date with sip and PyQt and vice versa (which wasn't the 
case earlier in the year), it shouldn't take much more than a week to have a 
KDE3.3 version available.

Jim