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