On 21.10.19 18:57, Chris Lamb wrote:
Matthias Klose wrote:
Thanks for the link. I don't immediately see how Lintian can
statically check for this lack of "looping" though. Can you help?
My idea would be to look at the .buildinfo file, seeing python3-all-dev, and
then python3.7-dev and python3.8-dev.
I'm still not 100% clear what you mean, particularly on the "seeing
python3.7-dev and python3.8-dev"? Perhaps if you could provide some
concrete good and bad examples that would be the most efficient way
to move forward from here.
The failures I want to catch are:
- build-depends on python3-all-dev, but only builds
for the default python3 version.
- build-depends on python3-all-dev, builds for all
supported python3 versions, but then somehow fails
to include the extensions for all python3 versions.
This seems to happen with 3.8, because the m modifier
in file and directory names was dropped.
The error should trigger,
- if the .buildinfo lists more than one python3.X-dev,
(this is usually only the case when python3-all-dev
pulls in more than one python3 version, like currently
in experimental).
- if the binary package python3-* has at least extensions
built for one python version,
- but not for all python versions you find in the .buildinfo.
The expected result would be an extension built for all
supported python3 versions.
this is a succeeding build which fails to package the 3.8 extensions:
https://launchpad.net/ubuntu/+source/python-crypto/2.6.1-10ubuntu1
https://launchpad.net/ubuntu/+source/python-crypto/2.6.1-10ubuntu1/+build/17935886
this is a fixed build:
https://launchpad.net/ubuntu/+source/python-crypto/2.6.1-10ubuntu2
https://launchpad.net/ubuntu/+source/python-crypto/2.6.1-10ubuntu2/+build/17938600
These are package which currently just bulld for the default but depend on
python3-all-dev:
ldb
apparmor
libkdtree++
zbar
