Re: Bug#766375: lintian: false positive with arch-qualified build-depends
+++ Niels Thykier [2014-11-04 07:10 +0100]:
> On 2014-11-04 03:58, Wookey wrote:
> > +++ Niels Thykier [2014-10-22 20:25 +0200]:
> >> [...]
> >> In particular, it is not clear to me whether (e.g.) "pkg:$arch"
> >> implies "pkg:any" or/and "pkg" (or/and vice versa).
> > I don't think pkg:$arch implies anything except pkg:$arch
> This is where we have our first disagreement and one of the reasons why
> I want someone to sit down and document this stuff. Since pkg:$arch
> installs an instance of pkg (for some architecture), then surely it
> would satisfy pkg:any at the same time.
OK. I understand your question now. Yes you are probably right. I'll
have to have a think about that.
> Lintian relies on "pure logic" when determining when a dependency is
> satisfied (unlike dpkg/APT, which look up the "target" package). We
> also use it to determine if the maintainer "screwed up" and duplicated a
> package in his/her dependency field.
> (Build-)Depends: pkg:any, pkg:amd64, pkg:i386, pkg:native, pkg
> Is there any redundancy in the above line? I am guessing "pkg:any" at
> least "pkg:any", but as I said "guessing" - and I do not like to guess
> on semantics of a dependency resolver.
> Keep in mind that even after you have done this, I get to solve the
> above question when versions etc. gets mixed into the line, like:
> (Build-)Depends: pkg:any, pkg (>= 1.0)
> Here, (*I* suspect) it should probably just have been a "pkg:any (>=
> 1.0)", but again - I am guessing...
> I am looking for documentation rather than code to reverse-engineer.
> Without any documentation clarifying how these relations interact, we
> will end up with 3+ implementations each doing it their own way with
> their own interpretations.
apt tries very hard to follow whatever dpkg does to avoid exactly this
problem. dpkg is the ultimate arbiter. Probably best to get the dpkg
maintainers to express an opinion here (cc:ed to the list)
I quite agree that we are missing proper documentation of this in
policy and it is now long overdue. I hope to find some time to at
least draft something soonish (when I get out from under current
Principal hats: Linaro, Debian, Wookware, ARM