[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Specifying Supported Python Versions - Round 2



On Wednesday, June 30, 2010 04:51:38 pm Piotr Ożarowski wrote:
> [Scott Kitterman, 2010-06-30]
> 
> > For Python3:
> > 
> > 1.  A new field called X-Python3-Version:  It does not support lists of
> > versions (e.g. (3.0, 3.1)).  Acceptable values are a single version (e.g
> > 3.1), greater than or equal to a version (e.g. >= 3.1), or strictly less
> > than a version (e.g. << 3.2).  Versions 2 or less will raise an error.
> > 
> > 2.  There is no #2.  If your build system uses py3versions -r, then you
> > need X-P3-V, if it's not there, an error will be raised.  If it doesn't
> > use py3versions -r, then it's between the maintainer and their build
> > system.   The field is not mandatory.
> 
> why? If py3versions is invoked in debian/rules, then there definitely is
> at least one python3-* binary package. Why do you want to make this
> field required? I'd make it optional and assume all 3.X versions if
> X-P3-V is not set.

I'm trying to minimize the amount of implicit magic we do.

There was strong consensus for Python 2 that "all" wasn't a great idea for XS-
P-V and so we point people away from it.  No implicit all seem the logical 
next step for Python 3 were we have more freedom to make things work the way 
we want.

If there's some consensus for an implicit "all" in Python 3, I won't object.

Scott K


Reply to: