Re: Python policy proposed changes
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 <abo@minkirri.apana.org.au>
Reply to: