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

[Simon Edwards]

On Tuesday 12 September 2006 01:59, Jim Bublitz wrote:
> On Monday 11 September 2006 11:47, Simon Edwards wrote:
> > Then if I have a KDE program PyFoo that includes a Python C module (or sip
> > wrapper) and was developed for KDE 4.0, it will called something PyFoo2.5
> > and require KDE 4.0 or later. When KDE 4.1 comes out maybe Python 2.6 is
> > also out, but the packager has also made a python2.5-qt and python2.5-kde
> > for KDE 4.1 which is enough to run the older PyFoo2.5 package. This can
> > only work if sip and libsip remain backwards compatible during the 
lifetime
> > of KDE4. Although not perfect, there is still a lot of compatibility to be
> > had without having to recompile everything everytime a new KDE and Python
> > come out.
> 
> > To make this possible PyKDE in KDE4 will need to support compiling to
> > different target Python versions. Another requirement we need to keep in
> > mind for KDE 4.
> 
> I guess I don't understand. I'd start from Phil's point - if a new Python
> rev  
> isn't binary compatible, then we'd be stuck with some version of Python for 
> the life of KDE 4., and so would anyone who developed for PyKDE/PyQt.

The important piece of information that you need is that distributions can and 
do ship *multiple* Python versions in the same release (and Debian does). 
This includes multiple versions of the same binary python modules, compilied 
for the different Python versions that they want to support. By supporting 
installation of multiple Python versions on the same computer, distributions 
can offer better backwards compatibility and phase in support for a new 
Python version while gently phasing out support for older versions. This 
saves distros from having to recompile everything all at once when moving to 
a new Python version, and allows other 3rd party packages to continue working 
without modification or recompile. Remember that not all of the packages that 
run on a given distro are created and managed by that distro.

> What I don't understand is where the problem occurs
> - PyKDE will build to  
> whatever version of Python sip and PyQt were built against, and won't build 
> against a Python without sip and PyQt. Apps written against those in Python 
> pretty much will only care if it's Qt/KDE 3 or Qt/KDE 4. Distributors can 
> tailor their installations so everything works - if some 3rd party bindings 
> need a specific sip/Python version, there's nothing to prevent that from 
> co-existing with whatever kdebindings uses, or whatever a user compiles sip, 
> etc against.

Consider this example. KDE 4.0 comes out with PyKDE included. PyKDE in KDE 4.0 
uses sip 4. This is all packaged by Debian along with python into these 
packages:

	python2.5 (version 2.5.0 of Python)
	kdelibs (version 4.0 of KDE)
	python2.5-kde (version 4.0 of PyKDE, contains the sip4 library)
	PyFoo2.5 

"2.5" is included in the name of these packages because these packages only 
work with Python 2.5. PyFoo is also specifically compilied for Python 2.5.

A developer writes PyFoo, a KDE app in python which also includes a C++ part 
which users and depends on sip 4. The package is called PyFoo2.5 and depends 
on package python2.5-kde.

Later Python 2.6 and KDE 4.1 comes out. The distro creates new packages of 
Python 2.6 and KDE, and also keeps python 2.5 around for compatibility. The 
list of packages looks like this:

	python2.5 (version 2.5 of Python)
	python2.6 (version 2.6 of Python)
	python2.5-kde (new version 4.1 of PyKDE, compilied for Python 2.5)
	python2.6-kde (new version 4.1 of PyKDE, compilied for Python 2.6)

Python 2.5 and 2.6 are both now happily supported. Python's poor module ABI 
compatibility is handled.

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?

cheers,

-- 
Simon Edwards             | KDE-NL, Guidance tools, Guarddog Firewall
simon at simonzone.com       | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."