• Reaching team consensus on usage of py3versions -r and X-Python3-Versio

    From =?UTF-8?Q?Louis-Philippe_V=c3=a9ron@21:1/5 to All on Mon Jan 17 18:50:02 2022
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------KoZQnsVwkm0i9GZQYOa6l37S
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    Hey folks,

    I'm following up on bug #1001677 [1] on the DPT's list to try to reach consensus, as I think the Lintian tags that were created to fix this bug
    are not recommending the proper thing.

    As a TL;DR for those of you who don't want to read the whole BTS thread,
    jdg saw that a bunch of packages were using `py3versions -r` in
    autopkgtests, and this fails when there's no X-Python3-Version variable
    in d/control.

    The fix that Lintian now proposes for packages that use `py3versions -r`
    in autopkgtests is to set X-Python3-Version.

    I think the proper fix would be to ask people to move away from
    `py3versions -r` if there is no X-Python3-Version, and use`py3versions
    -s` instead.

    As such, I think we should ask the Lintian maintainers to:

    1. Change the desc for tag declare-requested-python-versions-for-test to

    The specified test attempts to query the Python versions
    <em>requested</em> by your sources with the command <code>py3versions --requested</code> but your sources do not actually declare those
    versions with the field <code>X-Python3-Version</code>.
    .
    Please query all <em>supported</em> Python versions with the command <code>py3versions --supported</code> in your test instead.

    2. Change the desc for tag query-requested-python-versions-in-test to

    The specified test queries all <em>supported</em> Python versions with
    the command <code>py3versions --supported</code> but your sources
    request a specific set of versions via the field <code>X-Python3-Version</code>.
    .
    Please delete the field <code>X-Python3-Version</code>, as it is not needed.


    These changes would push maintainers to use `py3versions -s`, but
    wouldn't ask people using `py3versions -r` and X-Python3-Version to make
    any changes.

    AFAIU, the only valid use of X-Python3-Version would be a package that
    fails to build on an older but currently supported version of Python
    (let's say 3.9) but builds on the newer version (say 3.10). I think such
    use cases are pretty rare though.

    Cheers,

    [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001677

    --
    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
    ⢿⡄⠘⠷⠚⠋ pollo@debian.org / veronneau.org
    ⠈⠳⣄

    --------------KoZQnsVwkm0i9GZQYOa6l37S--

    -----BEGIN PGP SIGNATURE-----

    iHUEARYKAB0WIQTKp0AHB6gWsCAvw830JXpQshz6hQUCYeWrwAAKCRD0JXpQshz6 heRrAP9rDw7+ceiQqB05p87KnvU3+nBJNqOLsZsBbTgtqPh9OwD8CRPYELZCwyt0 grrTItm5CKoX+jqtupRFuvJev3K8Igc=
    =P+U8
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)