Re: Python policy update
On Fri, 2003-08-22 at 05:05, Josselin Mouette wrote:
> Le jeu 21/08/2003 à 04:24, Donovan Baarda a écrit :
> > --- 1.4 Module Path, a question;
> >
> > Do we really want /usr/local/ on the python path before /usr/lib/? This
> > makes us vulnerable to busted local installs of python modules, in the
> > same way that "#!/usr/bin/env python" makes us vulnerable to busted
> > local installs of python.
>
> Interesting question. The problem is then how to deal with a user/admin
> wanting to use a specific version of a single module and puts it in
> /usr/local.
Yeah... I dunno either... just noticed it and decided it might need to
be discussed.
> > --- 2.2.1 Support Only The Default Version, questions and typo on last
> > paragraph
>
> > I think "Build-Depends: python-dev (>= X.Y)" should be Build-Depends:
> > python-dev (>=X.Y), python-dev (<<X.Y+1)", or doesn't Build-Depends
> > support that. In any case, >=X.Y is not sufficient to nail it down.
>
> I happen not to agree for the build-depends. Having them set at
> python-dev (>=X.Y) allows for lazy rebuilding at the next python
> transition. The >= X.Y is here mostly for the autobuilders, as in fact
> the package could build with earlier python versions if it uses
> dh_python.
Can you really build a package that has "Depends: python (>=2.2), python
(<<2.3)" and puts files in /usr/lib/python2.2 with python-dev (2.3)?
I wouldn't think so... but perhaps I don't understand how Build-Depend
works.
> > --- 2.2.3 Support All/Most Versions (Including Default), regarding 2.
> >
> > Part 2. still includes the unsupported stuff about using
> > /usr/lib/python/site-packages. There was some discussion about using
> > /usr/lib/site-python for this instead... should this be updated?
>
> The two cases are different: /usr/lib/site-python is meant for the
> default python version, while /usr/lib/python/site-packages was meant
> for all python versions at a time. But maybe this should be completely
> removed or commented out as it is not likely to be supported in the near
> future.
Yeah, they are different. I'd probably say leave it there until we
figure out what to do.
> > --- 3.1 Version Independent Programs, comments
>
> > The last para about "private modules" should also apply against anything
> > that goes in /usr/lib/site-python and is only true because currently
> > there is no mechanism to re-compile version independent packages when
> > python (X.Y) upgrades. The moment python (X.Y) (and perhaps pythonX.Y)
> > is capable of identifying dependent packages and re-compiling them, then
> > there is nothing stopping dependencies like "python (>=2.0), python
> > (<<2.4)".
>
> Well, do you think the wording makes it unclear it is also true for
> stuff in /usr/lib/site-python?
I was mainly just commenting, but perhaps it should be more clear while
we don't support auto-recompilation... maybe some sort of rationale for
it? dunno. Perhaps something like;
TODO: currently there is no mechanism to recompile python modules when
the default 'python' package changes. This means packages that compiled
their modules using python (2.2) will not be recompiled with python
(2.3) when the python package is upgraded, unless they are re-installed.
Having "Depends: python (>=X.Y), python (<<X.Y+1)" ensures that the
package is upgraded, and hence recompiled, when the default 'python' is
upgraded. In the future a mechanism may be introduced to ensure packages
are recompiled automatically, allowing packages that support multiple
python versions to use dependencies like "Depends: python (>=1.5),
python (<<2.4)".
--
Donovan Baarda <abo@minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/
Reply to: