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 -- 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/20150418231742.gb15...@gaara.hadrons.org
