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

Bug#1001677: Comments regarding pytest-order_1.0.0-1_amd64.changes



On Sat, Jan 15, 2022 at 05:15:52AM +0000, Scott Kitterman wrote:
> This is certainly not a major issue, but your py3versions invocation in the
> autopkgtest is sub-optimal.  You are using -r for requested versions, but
> then the package doesn't request specific versions so if falls back to all
> supported versions:
> 
> $ py3versions -r
> py3versions: no X-Python3-Version in control file, using supported versions
> python3.10 python3.9
> 
> If you just use supported versions directly it's a little better:
> 
> $ py3versions -s
> python3.10 python3.9
> 
> Please update this in your next upload.
> 
> Scott K

Dear Scott,

Thanks for passing this through NEW!

The question of py3versions -r versus py3versions -s is not so
straightforward, IMHO.  Using py3versions -r protects against
the minor error of later introducing an X-Python3-Version field and
forgetting to change -s to -r.  With py3versions -r 2>/dev/null, the
correct behaviour is always obtained, as -r falls back to -s when
there is no X-Python3-Version field present.  Perhaps better would be
for py3versions to provide a -q flag to suppress the warning message
in this case; this would also protect against the error of using
py3versions incorrectly.

Furthermore, this idiom appears throughout the archive.
X-Python3-Version is quite rare: there are only about 194 occurrences
of it across the current unstable main archive, of which only 6 are
currently needed (those which specify X-Python3-Version: 3.9; all the
rest specify >= 3.x, with x at most 9).  On the other hand, there are
over 800 packages that use py3versions in their debian/test/* scripts,
but py3versions -r is very common among them, being used in a little
under half of the cases.  Only 4 packages have py3versions -r together
with X-Python3-Version (namely formiko, pyferret, python-rpaths and
sphinxcontrib-doxylink, though all of their X-Python3-Version fields
are now unnecessary).  There are also 4 packages which use py3versions
-s together with X-Python3-Version, and these work only because the
X-Python3-Version is now redundant (they are: mkosi, pyrlp,
python-ecdsa, python-libzim).

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001677 for a
little more detail (copied into this reply).

*If* the consensus is that py3versions -r is wrong, then we should
probably have a lintian check for it: py3versions -r (and variants
such as -rv and -vr) without a corresponding X-Python3-Version field
should give a lintian warning, and py3versions -s with an
X-Python3-Version field should do so likewise.

Best wishes,

   Julian


Reply to: