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 _______________________________________________ PyKDE mailing list [email protected] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
