[PyKDE] 10.0 official rpms for PyKDE

[Joachim Werner]

Hi!

Jim Bublitz wrote:

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

We just need the most current PyKDE source tarballs in time during the 
beta phase. Building is mostly automated, and as long as the tarballs 
don't differ much it should be no problem for us to update the RPMs for 
every beta (or at least every second or so).

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

OK. That's what I expected.

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

Yes, we can even do that in the build system after compiling and before 
packaging the binary RPMs ...

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

Same with us.

> I hope my earlier post wasn't taken as being angry or flaming

No, not at all ;-)

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

That's my main concern, too. The reason why I'm trying to get things in 
sync with our distro is that only if PyKDE comes with the distro people 
who don't know how to compile stuff on their own will be able to run 
Python-based KDE applications. And only if PyKDE becomes an integral 
part of the major Linux distros will we see a significant number of 
developers switch to PyKDE. A lot of people just won't use a tool if 
they have to install libraries from a third party first ...

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

Sounds great. My schedule for PyKDE/PyQt/SIP/eric3 on SUSE is trying to 
build "unofficial" SUSE LINUX 9.1 rpms for KDE3.2.3 as soon as this is 
possible. PyKDE is the only part that is missing on 9.1, but the other 
parts can need an upgrade, too.

For 9.2 (which should more or less match with KDE 3.3) we will then get 
the latest stuff released as part of the distro if everything goes well.

There's one thing I'll have to check with Stefan Kulow (the KDE release 
manager): If PyKDE becomes part of the KDE release itself we'll have to 
change the processes a bit. The guys who do the Java bindings are doing 
this already.

Cheers

Joe

-- 
Joachim Werner
SUSE RD-TPM