+++ 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/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150418214540.gd8...@halon.org.uk