Comment 44 for bug 1991606

The security update for distro-info, 0.18ubuntu0.18.04.1, was published in 2019. I don't think it's correct to say that this introduced the regression; the regression was introduced when upstream setuptools changed its behavior.

This does not preclude us moving forward with an SRU, I just want the record to be precise.

I do think the test case given in the bug report seems contrived. A number of packages are necessarily installed using apt to set up the environment; but then setuptools is specifically pulled from pip instead of from the Ubuntu archive? Why? Is there a test case that can be used to demonstrate the problem without what seems an unnatural mix of apt and pip?

My counterargument against this affecting CI pipelines is that, precisely because these packages are in all of our images, the SRU will also be seen on all Ubuntu systems - whether or not they are trying to use latest upstream setuptools - increasing the risk of a failure on upgrade; not because I think there's anything buggy about the proposed change, but because sometimes upgrade failures happen anyway, and while this normally doesn't weight very much, it's more of a consideration when there's a proposed update on the margin of the SRU policy to a core package.

I see that you have appropriately scoped the tasks on the various packages to only include those in releases where the version number curretnly violates the policy. Is the python-debian/kinetic task marked invalid because the version number there currently complies, or because when building with a source package version that doesn't comply the package will still be PEP440-compliant? If it's only the former, then it would be best if we did do an SRU of it but kept it in -proposed with block-proposed.