Bug#995490: lintian: false positive python3-script-but-no-python3-dep with Depends: python3, seems to want python3:any instead

[Helmut Grohne <helmut@subdivi.de>]

Hi,

On Sat, Oct 02, 2021 at 01:44:34AM +0100, Simon McVittie wrote:
> 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:

Unfortunately, that's still subtly wrong. Neither implication is valid.

If pkgD is not M-A:allowed, then a dependency on pkgD:any is
unsatisfiable while a dependency on pkgD is satisfiable. Therefore, pkgD
does not imply pkgD:any either.

>     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...

You basically got everything else right besides these implications. All
of the stuff that I snipped looks good and well presented to me.

When dpkg constructs binary packages, it merges multiple entries in
relation fields. If multiple substitution variables end up constructing
the same dependencies, dpkg fuses them. It knows about such
implications. It can even fuse an unversioned dependency with a
versioned one. Now if you look into packages that depend on a python
interpreter, you'll notice that they sometimes depend on both
python3.9:any and python3.9. calibre is an example, but there are more.
Now you know why.

> 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.

I suspect that people label me a domain expert for multiarch. May I
label Simon a domain expert on multiarch now? I could have hardly put it
any better. And the :any dependency on a non-M-A:allowed package really
is a corner case.

The TL;DR basically is:
 * lintian should accept interpreter dependencies with and without :any
   in the same way.
 * When lintian gives advice, it should recommend the variant lacking
   :any annotation.

Helmut