Re: arch-specific dependencies and M-A: foreign
Hi!
On Fri, 2015-04-17 at 11:27:07 +0200, David Kalnischkies wrote:
> Consider this situation:
>
> Native Architecture: amd64
> Foreign Architecture(s): i386
>
> and these two packages:
>
> Package: foo
> Architecture: amd64
> Depends: bar:i386
>
> Package: bar
> Architecture: amd64
> Multi-Arch: foreign
> Do you think 'foo' is installable?
No.
> What if we change the architecture of 'bar' to 'i386' and let 'foo'
> depend on 'bar:amd64', does that change anything?
No.
> What if we let 'foo' depend on 'bar' instead?
Yes.
> I ran some tests and dpkg and APT¹ disagree quite fundamentally here. dpkg
> declares 'foo' uninstallable in the first two cases and only the last
> one as okay, while APT is willing to accept all three situations.
Well, this was implemented, and subsequently fixed on purpose in dpkg to
match the docs (see commit 5631564609ec8855cdcab384139ca2e81c2519ce and
cdfd9738c03b772574443a61a2335ae934f0998e). The rationale is that if
you ask for an explicit arch-qualified dependency, then it means you
really want that one, otherwise why would you arch-qualify it if you
don't care which arch it is? Ignoring the arch-qualifier, regardless
of the package being M-A:foreign seems very wrong to me.
Check the lib/dpkg/depcon.c:deparchsatisfied() function comment, which
has not changed since the initial implementation.
> Now, imagine instead of 'bar' we had three other packages which provide
> 'bar'. Some of those providers are M-A:foreign, some not. What now? And
> to turn this up to eleven: Lets change 'Depends' to 'Conflicts' …
I guess I don't see the problem, either the metadata is wrong or the
packages will or will not have satisfiable dependencies.
> In other words my questions are: Is "bar:i386" referring to "bar:i386
> only" or is it referring to "everything implementing bar:i386"?
Anything implementing bar:i386 (assuming you mean a real package with
the former and a real or virtual package with the latter?).
> And is therefore also "bar" the same as "bar:amd64" (, "bar:native" and
> "bar:all") or not?
That depends on what bar is, or who is providing it.
dpkg does distinguish between implicit and explicit arch-qualified
dependencies when doing M-A:foreign checks. Let me give an example
to clarify all this:
,---
Package: pkg-a
Architecture: amd64
Depends: pkg-b, pkg-c:i386
Conflicts: pkg-d, pkg-e:amd64
Provides: virtual-a, virtual-b:armel
`---
These are the equivalences:
,---
pkg-b:amd64 implicit
pkg-c:i386 explicit
pkg-d:any implicit
pkg-e:amd64 explicit
virtual-a:amd64 implicit
virtual-b:armel explicit
`---
Conflicts, Breaks, Replaces → :any is implicit.
Pre-Depends, Depends, Recommends, Suggests, Enhances, Provides → :<arch>
is implicit, where <arch> is the architecture of the package with those
fields.
> My personal opinion is (unsurprisingly perhaps) APT's interpretation as
> the point of M-A: foreign is satisfying dependencies of another
> architecture. If there really is a meaningful difference between
> architectures a reverse-dependency could observe, perhaps bar should be
> M-A: allowed instead…
This removes expressiveness. If you don't care about the arch just do
not arch-qualify it, otherwise the arch-qualifier is relevant. And
this works nicely with both implicit :any or :<arch>.
> Beside this, I think it also provides us with some interesting benefits
> while changing a package from arch:all to arch:any (or v.v.) or
> a package moves from M-A:none to M-A:foreign (or v.v.). It could also be
> interesting if we ever get stuff like partial architectures…
I guess you'll have to spell these out, because I don't see any
obvious benefit, just drawbacks. :)
Thanks,
Guillem
Reply to: