KDE 4 (was: [PyKDE] PyQt 4 on openSUSE)
jbublitz at nwinternet.com
Tue Sep 12 22:30:07 BST 2006
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
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.
More information about the PyQt