Re: Python policy proposed changes
On Tue, 2005-10-11 at 20:23, Josselin Mouette wrote:
> Le lundi 10 octobre 2005 à 17:01 +0100, Donovan Baarda a écrit :
> > 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.
>
> The next section deals about such a scheme.
OK.
> > 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.
>
> I think the ftp-masters and/or release would object to having so many
> more source packages to deal with; I've heard it would cause problems
> when we went up with this kind of idea for GNOME metapackages.
What is worse, an extra very small source package, or a single large
source package that generates x large + 1 small binary packages (where
x=number of python versions supported) and gets upgraded more
frequently.
As an end user on a modem I know downloading all the binary packages
again when really only the python-foo wrapper dependencies changed hurts
much more, and I suspect this hurts mirrors more too.
> > 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.
>
> I agree, maybe we should remove documentation about things not working.
But it is handy to have wishlist stuff documented somewhere... perhaps a
wishlist bug?
> > 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...
>
> I wouldn't recommend this method, because of that possible .pyc
> autogeneration and the stale files it leaves in the filesystem.
It doesn't really leave stale pyc's, as they should still get cleaned up
when the package is removed. What it does mean is the pyc's that are
there might not be compiled for the right version. To help ensure that
they are compiled for the right version, the python.postinst should
re-compile everything in /usr/lib/site-python...
Another option would be for python.postinst to trigger
dpkg-reconfigure's for everything that has "Depends: python".
--
Donovan Baarda <abo@minkirri.apana.org.au>
Reply to: