--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: lintian: false positive python3-script-but-no-python3-dep with Depends: python3, seems to want python3:any instead
- From: Simon McVittie <smcv@debian.org>
- Date: Sat, 2 Oct 2021 01:44:34 +0100
- Message-id: <YVerchnRKva/zgyi@momentum.pseudorandom.co.uk>
Package: lintian
Version: 2.107.0
Severity: normal
xdg-desktop-portal-tests has a python3 script. It also has
"Depends: python3".
This is now diagnosed as "python3-script-but-no-python3-dep"; looking at
recent commits, Lintian seems to want it to depend on python3:any instead.
I think that's incorrect: a dependency on either python3 or python3:any
guarantees that some sort of /usr/bin/python3 will be available, so
either one should be considered to be acceptable, and the tag should
only be emitted if neither of those dependencies is present.
For *many* use-cases, a dependency on python3:any is *preferred*: it'ss
a less specific dependency than python3, as I'll explain further below,
so it constrains the dependency solution less (and in particular it's
helpful to people who want to cross-compile or install packages from a
secondary architecture). However, for *some* use-cases, a dependency on
python3:any would be incorrect, and only a dependency on python3 would be
sufficient - so we cannot recommend python3:any over python3 in all cases!
If we could, then the :any qualifier would be pointless.
I think most (maybe all) of the tags of the form "you have a script whose
interpreter is foo, so you need a dependency on package-containing-foo",
where package-containing-foo is Multi-Arch: allowed, should accept either
package-containing-foo or package-containing-foo:any as being sufficient
to provide the required functionality.
I think (but I'm not 100% sure yet) that this is to do with a bug in the
recent changes to Lintian::Relation::Predicate, in which the "implies"
relationship seems to be reversed in some cases. Have those changes been
checked by someone with in-depth knowledge of multiarch?
---
Further explanation:
Looking at the recent commit
https://salsa.debian.org/lintian/lintian/-/commit/9bc560a6 I think there's
maybe some confusion about what the :any qualifier on dependencies means,
which might be contributing to this.
Suppose we have these packages, which represent the four possible Multi-Arch
policies:
- dbus: Multi-Arch: foreign
- python3: Multi-Arch: allowed
- libglib2.0-0: Multi-Arch: same
- libopusfile0: no Multi-Arch field (sometimes said to be "Multi-Arch: no")
If I have a dependent package like this:
Package: dependent
Architecture: amd64
Depends: dbus, python3, libglib2.0-0, libopusfile0
then what that effectively means is that it depends on:
- dbus of any architecture (because dbus has M-A: foreign)
- python3:amd64
- libglib2.0-0:amd64
- libopusfile0:amd64
If I changed my dependent package so that, instead, it was like this:
Package: dependent
Architecture: amd64
Depends: dbus, python3:any, libglib2.0-0, libopusfile0
^^^^
then the result is that it depends on:
- dbus of any architecture
- python3 of any architecture (this is what has changed)
- libglib2.0-0:amd64
- libopusfile0:amd64
The reason why packages like python3 can be depended on in two different
ways is that they can be used in two different ways.
If I just write a pure-Python script with #!/usr/bin/python3, then I can
run it with any python3 interpreter that I can execute. On my amd64 system,
I would usually want to run it with python3:amd64, but if I wanted to,
I could install python3:i386 and run it with that (or I could even install
python3:riscv64 and qemu-user, if I was feeling ambitious). In this
situation, I can safely use "Depends: python3:any". This is the "weaker"
dependency that provides fewer guarantees, and I think it is the common
case in practice.
However, suppose instead that my script contains "import dependentlib",
where "dependentlib" is a Python 3 module written in C or C++ and included
in the dependent package. Now the situation has changed. If the package
that I have installed is dependent:amd64, then I cannot run my script
using python3:i386, because I do not have an i386 version of dependentlib:
I must specifically have python3:amd64. So I need to depend on
"Depends: python3" and get a python3 of the same architecture.
The version without :any is the conservative choice, which might be
harder to install but is always OK, so it gets the unqualified syntax. The
more liberal dependency with the opt-in :any qualifier is preferred *if*
it is sufficient, but it is not always sufficient.
Going back to the package that triggered this bug report, it would
*probably* be valid to change xdg-desktop-portal-tests to depend on
python3:any, but I have not done the analysis to prove that, and until
someone does so, the safe, conservative option is to continue to depend
on python3.
Other interpreters that have a C API, such as Perl and Ruby, are in the
same situation as Python: it is *often* better to depend on them with
the :any qualifier, but not always.
In the code changes in
https://salsa.debian.org/lintian/lintian/-/commit/9bc560a6 I'm particularly
suspicious about these two test-cases:
my $orig = 'pkgA:any, pkgB, pkgC:i386';
my $relation = Lintian::Relation->new->load($orig);
...
ok(!$relation->implies('pkgB:any'), 'pkgB does not imply pkgB:any');
...
ok($relation->implies('pkgA'), 'pkgA:any implies pkgA');
because I think they are the wrong way round. If the meaning of
"$relation->implies($x)" is something like "for every set of installed
packages that would satisfy the dependency relation $relation, we can
prove that the same set also satisfies $x" (in other words $relation is
an equal or stronger dependency than $x), then I think the correct
test would be this:
my $orig = 'pkgA:any, pkgB, pkgC:i386';
my $relation = Lintian::Relation->new->load($orig);
...
ok($relation->implies('pkgB:any'), 'pkgB implies pkgB:any');
...
ok(!$relation->implies('pkgA'), 'pkgA:any does not imply pkgA');
However, it's late at night so don't 100% trust me on that...
Multiarch is complicated and sometimes confusing even for experienced
Debian developers, and less-experienced developers often follow Lintian's
advice without applying much critical thinking to it, so I would recommend
getting feedback from a domain expert before making changes that emit
additional multiarch-related hints - it would be counterproductive for
Lintian to be giving wrong advice.
smcv
--- End Message ---
--- Begin Message ---
Source: lintian
Source-Version: 2.109.0
Done: Chris Lamb <lamby@debian.org>
We believe that the bug you reported is fixed in the latest version of
lintian, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 995490@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Chris Lamb <lamby@debian.org> (supplier of updated lintian package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Format: 1.8
Date: Fri, 15 Oct 2021 08:01:45 +0000
Source: lintian
Architecture: source
Version: 2.109.0
Distribution: unstable
Urgency: medium
Maintainer: Debian Lintian Maintainers <lintian-maint@debian.org>
Changed-By: Chris Lamb <lamby@debian.org>
Closes: 994902 995490 995498 995981 995991 996093 996111 996270
Changes:
lintian (2.109.0) unstable; urgency=medium
.
* Summary of tag changes:
+ Added:
- redundant-build-prerequisites
- redundant-control-relation
+ Removed:
- duplicate-in-relation-field
- package-has-a-duplicate-build-relation
.
[ Felix Lechner ]
* Do not complain about library sections that do not exist.
(Closes: #995991)
* Python :any handling:
* In tag descriptions, never ask for :any in Python prerequisites.
(Re: #995498)
* Fix processing of the :any multiarch acceptor in package
relationships. (Closes: #995490, #995498)
* Allow make:any as a prerequisite for using usr/bin/make in scripts.
(Closes: #994902)
* Make the condition of a missing interpreter look less like
a recommendation.
* Fix non-sensical line lengths in hints from cruft check.
(Closes: #996111)
* Add a new Lenna image to the list of banned files. (Closes: #996093)
* Also allow private folders in lib from custom library search path.
(Closes: #996270)
* Clarify in tag descriptions for debian/rules check that hint context is
not a recommendation. (Closes: #995981)
Checksums-Sha1:
148e6542a76294d915a9d50c7c7ce691cf9feb10 2486 lintian_2.109.0.dsc
7018ec87b22ae2062ccf447646a0abed75174c52 2073516 lintian_2.109.0.tar.xz
62b117376aa1eeabacc42a7c67315569c8a1b249 6550 lintian_2.109.0_amd64.buildinfo
Checksums-Sha256:
c5750dd7e890e62e26ee9bf8d89f288cdd3ae5265c4d99ad49a852debb33f6df 2486 lintian_2.109.0.dsc
f7ff3fa2938867205abba4fc4e8b35a6323c59cf941e7a364faf94edce087712 2073516 lintian_2.109.0.tar.xz
a6fcdc1603495c1cf0f8871a7b9d5a47d0c7f98872d68401819a0a17d959e230 6550 lintian_2.109.0_amd64.buildinfo
Files:
ac747a8841f0332a39f0920558db507a 2486 devel optional lintian_2.109.0.dsc
33a5984b04f930f603d19ea953e1bf3c 2073516 devel optional lintian_2.109.0.tar.xz
5db56713a4a53543a8b129b0848bfc22 6550 devel optional lintian_2.109.0_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAmFpNfsACgkQHpU+J9Qx
Hli6/Q/+LRajXy0NdwhsDN6xXFNQ5YiLrEOEx+yBtjILG8+m6e+99vHMjbDgH4ox
kUBhTNswJoNxTE4SXQNXJJAZO/gnLaxJjs0L+JHG3DHuHSY87+ZAMqzr1eLoaen2
Rn+i2sCgNEU2Y+K5oWU2hhMs9kXcYtYs8ofmVGo37uvQLuBxeqns59diKh3Lvq+X
MLytXuXlaAhPqT/fNNbhjqu3KTcD1FqjDpHcnwMJTQWe/mWbNHMkJZ2065Uthj+z
ptHPlyjGHVKsNeDY0i9vqgG+rytf7HTwpZMvKdHXqdnwVirtTG9MqsMazKCrKmxw
iwjAPVin4byEs2GJI29AFHMafBHMcXV2QzkcpwSgYuRGUgWQK2i1qggzDqVM+qj2
ZDhbttzQAv4HDBhovFtqmv7LxQDrGozZXzGEN3Bjm9O5/DiNvkN3S0OudzjYEq9j
9EkUT73ObEBnru3RAP5zuCo6qD5rjI7Glk+r9Qu5ECgEgxbi4dClYAFI9CejRVwC
nEsGEljN9Yf+CNccdZ7p2U9nodnc4vvFHvq0N9zgbVkxwk3sDPfm5U4wgIaOP44W
elmA0ZYpOxlDtFutHKkEdlBpXOkFY+g3YnU+4yUVBt5YMhS7Kj27EobOtv2AOWwi
c5qSDl8Xq1LIrDGQS3RJPCxjmEph9LOFQjKynkhrv9KzNPxWxNg=
=rjRD
-----END PGP SIGNATURE-----
--- End Message ---