I can't say I understand half of what you guys are discussing but I regularly encounter issues with zope and associated py-modules. I use the latest version of python with my own scripts but any time the system requires updating, any kind of automation (rolling replace namely) refuses to acknowledge I want to update both py24 modules and py25/py26. The end result is that only the preferred version modules remain, leaving me to figure out what I need to reinstall. I haven't checked it lately, so it may not be relevant ... actually, this may not be relevant at all but I thought I'd mention it :) The issues being discussed is that there are some packages that install files in a python-version-specific directory, but don't have a pyXY- prefix, and most people think that's a bug. Your issue is one I've encountered and is a bug/not-yet-implemented feature in pkg_chk, make replace or pkg_rolling-replace. As an example, there is a package py25-foo installed, with the default python version set to 26. pkg_chk reports that this package is out of date, perhaps because 25/26 or perhaps because it's been updated (on the package version side). Then pkg_rolling-replace calls 'make replace', and it finds PKGPATH from the installed package, and builds py26-foo, and when it tries to deinstall py26-foo fails because it wasn't ever there. I think the fix is (some of this may be ok already): make pkg_chk understand pyNN-foo-X.Y, in that such packages are out of date only if foo is at other than X.Y, even if NN != PYTHON_VERSION_DEFAULT. make the way make replace checks for old versions also respect this that might be it, but pkg_rolling-replace might need some fixes too. Perhaps an option to add packages pyPVD-foo if that doesn't exist and there is a pyOV-foo. Or perhaps only if one is changing the default version of python. Presently changing the default version is messy.
Attachment:
pgpDPxkoBC_9H.pgp
Description: PGP signature