Re: arch-specific dependencies and M-A: foreign
+++ David Kalnischkies [2015-04-17 11:27 +0200]:
> Hi Multi-Archers!
>
>
> 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? What if we change the architecture of
> 'bar' to 'i386' and let 'foo' depend on 'bar:amd64', does that change
> anything? What if we let 'foo' depend on 'bar' instead?
> In other words my questions are: Is "bar:i386" referring to "bar:i386
> only" or is it referring to "everything implementing bar:i386"?
> And is therefore also "bar" the same as "bar:amd64" (, "bar:native" and
> "bar:all") or not?
>
I had assumed that bar:<arch> meant that specific arch, but only
because that's the way I've used it (in cross-toolchains, depending on
MA:same things), and I've not thought about the implications of this
where the depended-on thing is MA:foreign.
> 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.
OK. That's not good.
We badly need to document multiarch properly in policy, ideally
well-enough that this sort of thing is clarified. I did start work on
that, but didn't get much beyond realising that the policy docs
structure is nothing like the MA spec structure so putting the latter
into the former is harder than one might like. (And also that I didn't
know the answer to lots of difficult questions like the one you pose
above).
> 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…
That seems reasonable to me.
Would some kind of multiarch session at debconf be useful to have
higher-bandwidth discussion on these sorts of points. I think if we
had an initial draft of policy we could sort out some of these things
in such discussion? But perhaps it's all so esoteric that doing it by
mail over a longer period would be more effective?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Reply to: