On Monday 06 November 2006 08:18, Andreas Pakulat wrote: > On 05.11.06 19:20:00, Simon Edwards wrote: > > I don't think that is quite the case. The standard approach that > > distributions > > use for this kind of problem is to make it possible to install the old > > version along side the new one. This is very common for shared libraries > > for > > example. > And they also re-compile their apps against the newer version as soon as > possible, so they can obsolete the old version and drop it. Because > maintaining 2 or more versions of the same lib is a nightmare.
True. But as a user I can still install the new version along side the old one. > > > If you are using out of distro packages you expect to have to recompile > > > them > > > from time to time. The most obvious example is if your distro updates > > > it's > > > version of Python - you have to recompile your extension modules, > > > whether > > > they are SIP based or not. > > I am fairly sure that that is not how Debian handles Python these days. > Actually it is. but the old ones keep working. That's the point. > Well, different Python versions and especially their extension modules > are installed into totally different prefixes. > > Lets say SIP version X is coming out and uncompatible with version Y > (X>Y) then Debians python maintainers do one of two things: > > a) Prepare a new upload of sip (version X) to unstable, upload it and > when it hits unstable recompile all the dependant modules, which > currently is PyQt3/4 and PyKDE - AFAIK That's the trick. Right now the list of dependant modules is very short and manageable and doesn't form a big problem. I'm thinking about the future where this list may be much longer and no longer manageable. > This is no different than an upgrade of libstdc++ would work, if they > change their ABI or even API. You can't install 2 versions of that > either, because as soon as the "basic libs" (like Qt for > Qt/KDE/PyKDE/PyQt apps) compile against it your applications will break > and you have to recompile everything. libstdc++ is a different case since it depends on so much stuff it is not practical to produce separate packages for applications that are compiled against different libstdc++ versions. This is different than the situation for Python modules. They are packaged in separate packages which can be installed in parallel (e.g. python2.4-ldap and python2.5-ldap). Mind you, looking in the package manager right now I can see 5 different versions of libstdc++ that I can install if need be. > And when you compare the situation of PyQt3/PyQt4 to that of old/new sip > version your comparing apples and pears. The proper comparison would be > between 2 different versions of PyQt4, which cannot be installed > together and you might have a similar problem there. I _am_ talking about installing two different versions of PyQt. One compiled on sip API X and another with sip API X+1. I would like that to work as smoothly as PyQt3 and PyQt4. I guess that at the end of the day it is not a urgent problem today. There are very few applications that use SIP, and if a developer needs to use optimise something they can use C and maybe the new 'ctypes' module in Python 2.5. This problem is something which developers and packagers need "keep in the back of their mind" so to speak. Also if sip API versions become a problem for a distro, they could still combine a move to a new sip API version with a new Python version. I mean, have PyQt4 + sip API version X for Python 2.5, and but then for Python 2.6 compile PyQt4 with sip API X+1. They would work out too. Python versions do come out regularly. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | "ZooTV? You made the right choice." _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
