Le ven 22/08/2003 à 04:37, Donovan Baarda a écrit :
> 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.
Both orderings have their problems, maybe the situation of local python
installations should be rethought.
> > > --- 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 (< > > 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.
What I mean is that you can have a source package with
Build-Depends: python-dev (>= 2.1)
which generates binary packages with
Depends: python (>= 2.2), python (<< 2.3)
or
Depends: python (>= 2.3), python (<< 2.4)
etc. depending on the current python version installed on the building
machine.
In this case, the strict build dependency on python-dev (>= 2.3) is only
here to ensure the autobuilder has the right version installed.
Is this more clear?
> > > --- 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 (< 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)".
Sounds reasonable.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
