On Sun, 2005-10-09 at 11:42, Josselin Mouette wrote: > Hi list, > > prior to the upcoming python 2.4 transition, I've drafted some small > changes we've already talked about on this list: > http://people.debian.org/~joss/python/python-policy-draft.html/ > > Apart from a typo and the FSF address, the changes are about which > packaging variants are mandated, recommending to provide only one > python-foo package for each module, except when depending applications > mandate another python version. > > This way, we could enforce that policy during the transition, removing > hundreds of cruft python2.X-foo packages. > > Any thoughts? Any other things that should be changed?
In 2.2.2, I would remove the "only" from "only supports python versions different from the currrent default one"... You can use this for packages that support the current default one as well as other versions. In 2.2.3, part 1. I would recommend (mandate?) that the python-foo dummy wrapper package should have it's own tiny source package, seperate from the pythonX.Y-foo source package. This way, only the small python-foo wrapper package needs to be updated and re-built when the default python changes. For 2.2.3 part 2, I don't know what to do... there has been no progress in making this work for a long time, and I don't know if there ever will be. It's probably still worth documenting as a wish list, but I can't help but think it's overly complicated somehow. Another alternative for 2.2.3 part 2 is the practice adopted by some pure-python packages of putting modules in /usr/lib/site-python, which can be found on the default sys.path of all versions of python. The ugliness of this is the pyc's get recompiled for different versions of python, and will be re-written if the user has write access there. For all it's drawbacks, it is a much lighter alternative to the mass of symlinks approach... -- Donovan Baarda <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]