[PyKDE] 10.0 official rpms for PyKDE

[Jim Bublitz]

On Wednesday 26 May 2004 01:27, Joachim Werner wrote:
> > 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.

> > 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.

>  From the SUSE point of view I'd be fine if I could get hold of late
> betas or release candidates a week or two after the KDE release that
> preceeds our SUSE LINUX product. The enterprise products are always
> based on the same code base, and we can make sure during the enterprise
> beta phase that we become aware of any changes in KDE that would break
> PYKDE.

> That would mean that we can get things in sync during the beta phase and
> release the latest KDE with the latest bindings.

>  From what you are saying this might work for the next SUSE LINUX. :-)

I wouldn't mind doing this for any distribution. I can't promise to test 
against every beta/rc since both the download time and build time/build 
problems can be a lot of extra work. I can try to keep up with the rc 
releases and submit packages to you.

Generally there are two problems: keeping PyKDE and sip in sync and keeping my 
tools in sync with KDE. We should be entering a phase where PyKDE and sip 
"get along" very well in terms of sip changes that affect PyKDE and KDE 
changes that require sip enhancements from Phil. Minor releases like KDE 
3.2.3 should require almost no work on my part. Major releases like KDE 3.3.0 
have required more work in the past because new C++ language features appear 
(nested template-based classes in kconfigskeleton in KDE 3.2) and the kdelibs 
hierarchy sometimes gets rearranged (for example kfile was folded into libkio 
quite some time ago).

I'm expecting though that KDE 3.3 will be fairly easy as major releases go 
because both sip and PyKDE tools have improved a lot as far as C++ features 
supported. KDE4 may be harder, but there will probably be a lot of time to 
work out those issues. Most of the problems will show up in the early betas, 
so if I work with those, I should be able to have a final release fairly 
quickly.

> I can't speak for the other distros, but I guess none of them release
> their final products earlier than a couple of weeks after a major KDE
> release ...

> > 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).

> If there are any automated tests we could run them as part of our QA
> efforts. And of course we can provide betas to you ...

The major issue is that the code base the distro uses has to match the code 
base PyKDE is written against in that every class/method has to continue to 
exist and every method has to have the same argument list (as well as the 
obvious - having a compatible sip/PyQt version).  If that doesn't happen, one 
or more PyKDE modules won't be loadable under Python. So all that's necessary 
is to run the importtest.py script that comes with PyKDE. All that does is 
try to import each module. New methods shouldn't cause a problem - PyKDE just 
won't know about them. Repairing any problems is usually pretty trivial - 
comment out missing stuff, or modify an argument list.

You could probably run importtest.py as part of the rpm install if you wanted 
to.

That doesn't guarantee that PyKDE is 100% correct, but it does guarantee that 
everything is compatible and PyKDE is usable.

As far as betas, I assume that involves downloading a few CDs worth of data. 
I'm on a satellite link and it isn't the most reliable bandwidth for 
downloads that large. However, Hans-Peter Jansen is very familiar with PyKDE 
build procedures and problems, and becoming familiar quickly with PyKDE 
internals, so he might be a good candidate to do that kind of testing - if 
he's interested. I'd support him as much as needed, of course.

I hope my earlier post wasn't taken as being angry or flaming - I'm very 
interested in working with SuSE or other distributors, but the main concern 
is getting something usable and reliable to PyKDE users (which I haven't 
always succeeded at).

Just let me know how you want to handle this and we'll see if it can be worked 
out.

Jim