Maurice LING wrote:
technicalities are wrong but situation remains unchanged.
For C modules, it is very likely that new versions of Python will continue to break the ABI, by changing the layout of structures.
The most straight-forward way to deal with it as a sysadmin or user is to install multiple versions of Python on a single machine. If Fink considers python2.4 as a replacement for python2.3, then this is a flaw in Fink. In Debian, there is a python package, which currently depends on python2.3. Sometime in the future, it will depend on python2.4. Users which update will then get python2.4, however, python2.3 will remain installed and usable, with all the extension modules that were installed for it.
Regards, Martin
Fink does not consider python2.4 to be a replacement for python2.3. In fact, you can install python2.2, 2.3 and 2.4 in the same machine with Fink. It will maintain 3 sets of libraries as /sw/lib/python2.2, /sw/lib/python2.3 and /sw/lib/python2.4. The chore is that when say Fink installs python2.4, all the libraries in /sw/lib/python2.3/site-packages have to be re-installed into /sw/lib/python2.4/site-packages, one by one. There is no simple way of doing that... which makes any system admin needing to re-install 50 3rd party libraries into /sw/lib/python2.4/site-packages a big task, as well as satisfying the necessary dependencies.
So if C extension API (or whatever that is really called) is stable, the system admin can just copy all of /sw/lib/python2.3/site-packages into /sw/lib/python2.4/site-packages and it should work. From what you've said, it seems that this isn't possible. So my alternative solution is that PyPI have a mechanism to maintain what had been installed in the site-package directory and to download the libraries and install into the new site-package directory...
What do you think?
Cheers maurice -- http://mail.python.org/mailman/listinfo/python-list
