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