KDE 4 (was: [PyKDE] PyQt 4 on openSUSE)

[Jim Bublitz]

On Tuesday 12 September 2006 12:08, Simon Edwards wrote:

> Now the problem is the old PyFoo package. It depends on python2.5-kde
> version 4.0 or better and hence sip 4, because sip 4 is what shipped in KDE
> 4.0. This is the version of sip that PyFoo runs on. If the new
> python2.5-kde package for KDE 4.1 includes a different and incompatible
> version of sip (say sip 5), then the PyFoo2.5 will not work.

> > Anything in KDE should be consistent in the Python version it uses - KDE
> > already forces lib installs and even new Qt installs with each release.

> Yes, KDE may force the installation of newer libraries. But the policy is
> that stuff that runs on an older KDE will still run on a newer KDE. (in the
> same series of course). Newer versions of libraries still run software
> which was build for the older version.
>
> Am I having any sucess in explaining why PyKDE in KDE4 will need to
> maintain backwards compatible sip versions during the lifetime of KDE4?

Well, I guess I do understand. From my perspective, what counts here is the 
starting and end points of the situation you describe. The starting point is 
a developer (somewhat like me embarrassingly) who doesn't maintain his 
package in sync with newer sip versions. The end point is that sip would be 
constrained in its development if the Python ABI changes or Phil develops 
some significant improvement, at least for the life of KDE4.

I'd slice this a different way though. The situation is already such that 
what's in KDE is (version-wise) independent of what Phil or I release. So 
there isn't anything to stop KDE from maintaining a consistent version of sip 
over the life of KDE4. Once a PyKDE version builds against sip version, there 
are almost no errors that pop up, so about the worst result of that kind of 
policy would be that an unusual new feature in KDE might go unsupported.

On the other hand, the set of sip/PyQt users is not identical to the set of 
KDE users - sip/PyQt support two other platforms where KDE generally doesn't 
run, and even on Linux, not all sip/PyQt users are KDE/PyKDE users. I think 
it's desireable to give those users the best platform possible, regardless of 
KDE compatibility.

Going back to the starting point above, I don't think it's reasonable to 
restrict non-KDE users, and even the majority of PyKDE users, because some 
developer (who isn't even releasing as part of the 'official' KDE project) 
doesn't stay current.

It looks to me like there's a tradeoff here - you can maintain a stable sip 
for KDE, or you can have the latest-and-greatest sip, but in some cases, you 
can't have both. 

In fact, if sip had maintained binary compatibility throughout KDE 3, it's 
unlikely that any of the stuff that you, David and I worked on (panel 
applets, IO slaves, control center modules) would work, because sip3 and 
older versions of Python had threading problems that we never found a 
solution for, whereas sip4 and newer Pythons work just fine.


Jim