On Jun 30, 2010, at 04:58 PM, Scott Kitterman wrote: >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. The question that comes to mind is why Python 2 and Python 3 would have different rules? If there's a good reason (e.g. it cleans up a backward compatibility wart), then cool. If not, then consistency between the two might make a reasonable default. -Barry
Attachment:
signature.asc
Description: PGP signature