On Tue, 10 Apr 2018 09:19:55 +0100
Chris Lamb <lamby@debian.org> wrote:
> Hi Neil,
>
> Apologies, but I am now more confused than ever. When I look at your
> link, ie.
>
> https://github.com/Linaro/pkg-lava-server/blob/master/debian/control#L79
>
> I see:
>
> libjs-jquery-ui, python3:any,
It's a git repo, things change... there is history ...
The historical version of the file at the time in question is:
https://github.com/Linaro/pkg-lava-server/blob/b1c7feeefc13fd5788f8c35411f4b3039380b483/debian/control
>
> whilst you quoted in your previous mail:
>
> libjs-jquery-ui, python3 | python3-all | python3-dev |
> python3-all-dev
>
> I also remain confused why we are using python3 here as the .deb I
> downloaded had a Python 2.x shebang.
The URL is a staging-repo containing nightly builds (plus some older
builds for some corner cases). The current URL for lava-dev is
http://images.validation.linaro.org/staging-repo/pool/main/l/lava-server/lava-dev_2018.2+7178.53c57de9-1+stretch_all.deb
The python scripts in that binary are all in /usr/share/<PKG_NAME>/ and
all have a Python3 shebang, as will be all future builds.
Upstream are in the middle of transitioning the entire codebase from Python2
runtimes to Python3 runtime. We've had Python2 & Python3 unit test
support for a while, now we're dropping the packaging of anything
Python2 and moving the scripts to Python3.
We have not made a release based solely on Python3 yet, so we have not
uploaded to Debian, yet. So all changes, development, testing and
debugging is on a constantly moving master branch.
> > Maybe this is a bug in dpkg:
> […]
> > Lintian needs to check for this behaviour of dpkg-gencontrol and
> > skip the python-script-but-no-python-dep check if there are no
> > scripts in usr/bin or usr/sbin in the binary package. dpkg seems to
> > not care about /usr/share.
>
> I am not sure what behaviour of dpkg you believe this is triggering
> and/or what is so special about /usr/share.
Irrespective of Python2 vs Python3, if a Python package installs
scripts *only* into /usr/share then dpkg-gencontrol does not populate
${python3:Depends} and also removes any mention of python3 |
python3-all | python3-dev | python3-all-dev which causes lintian to
complain.
>
> Perhaps you are not calling dh-python entirely correctly? I am unsure
> and I would would have to leave it with you to debug.
I'm working around this whole mess with:
https://github.com/Linaro/pkg-lava-server/commit/ac3f2ef4e9b796f1176305f885fa815d0c756508
>
> I still don't see (or, more likely, comprehend) any bug in Lintian
> here, sorry — the generated .debs I have seen appear to be triggering
> this correctly.
From the last email:
> Maybe it is because lava-dev puts all it's scripts
> into /usr/share/lava-server?
>
> Indeed, artificially changing debian/lava-dev.install to put one of
> the scripts into /usr/sbin fixes the problem. The variable is
> substituted as python3:any and lintian doesn't complain (it complains
> about other things now but not this false positive).
>
> Lintian needs to check for this behaviour of dpkg-gencontrol and skip
> the python-script-but-no-python-dep check if there are no scripts in
> usr/bin or usr/sbin in the binary package. dpkg seems to not care
> about /usr/share.
>
> Arguably it's a bug in dpkg-gencontrol which could catch out binary
> packages which only put minimal Python3 scripts in /usr/share but it's
> unlikely to be caught that way as some dependency will end up being
> added by the maintainer on one python3 module or other.
>
> Replacing the python3 | python3-all | python3-dev | python3-all-dev
> with python3:any actually fixes the problem but then that isn't needed
> except when all the scripts are installed into /usr/share/ so that's
> anachronistic and undocumented Debian "magic" but it's what I'll use
> to workaround this bug. Other binaries in the same control file don't
> need either:
> python3 | python3-all | python3-dev | python3-all-dev
> or
> python3:any
So, to summarise:
Lintian needs to stay in step with dpkg - dpkg does not generate a
${python3:Depends} substitution if none of the python content of the
binary package is in /usr/bin or /usr/sbin. Therefore, lintian should
not be checking / complaining about python-script-but-no-python-dep if
there are no python scripts installed into /usr/bin or /usr/sbin
because that raises a false positive. The packaging can assert what it
likes but unless a python script exists in /usr/bin or /usr/sbin, dpkg
ignores it and lintian gets it wrong.
Alternatively, lintian is interpreting Policy correctly and dpkg is
getting Policy wrong. Then, this bug needs to be reassigned to
dpkg-gencontrol so that dpkg *does* check /usr/share/<SRC_PKG_NAME>/
and then populate ${python3:Depends} so that lintian is happy.
What we should *not* be doing is forcing this kind of workaround by maintainers:
https://github.com/Linaro/pkg-lava-server/commit/ac3f2ef4e9b796f1176305f885fa815d0c756508
It all comes down to a python source package which builds more than one
python binary. One or more of the binaries only installs python
scripts into /usr/share/<SRC_PKG_NAME> and that will trigger the bug.
Change the .install to put even one python script into /usr/bin
or /usr/sbin and the bug disappears.
Add the workaround above and the bug disappears. The workaround isn't
needed for any package that installs precisely the same python scripts
in /usr/bin or /usr/sbin - that's why this whole sorry story exists.
That should be relatively easy to test.
What is going wrong is that lintian and dpkg disagree on what is correct.
lintian either needs to not check /usr/share or this gets reassigned to
dpkg-gencontrol to make dpkg check /usr/share.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
Attachment:
pgp0y_uLakLk2.pgp
Description: OpenPGP digital signature