Hi David, Quoting David Kalnischkies (2015-04-17 11:27:07) > In other words my questions are: Is "bar:i386" referring to "bar:i386 only" > or is it referring to "everything implementing bar:i386"? the latter in my understanding. As far as I understand dependencies, a string like "foo" in a Depends field does not mean "I require a package of exactly the name foo" but "I require something that can give me foo". In dose3 this is why these strings are called "virtual" packages because they are not necessarily actual packages (even if they are probably in the most cases). > And is therefore also "bar" the same as "bar:amd64" no because different packages might provide "bar" and "bar:amd64". So even on amd64 this dependency might be resolved differently. > (, "bar:native" and "bar:all" Is there a point in allowing to explicitly depend on a package of Architecture:all? Does this work with apt? >) or not? dose3 agrees with apt here and is able to install "foo" in all three of your scenarios. This is because as far as dose3 is concerned, the dependency bar:i386 is satisfied by every provider of bar:i386. This can be either a package bar which is M-A:foreign and (in the future, after a bug [1] is fixed) also a package "blub" which Provides: bar:i386. > 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… Yes, if bar:amd64 would not also really provide bar:i386, then it should not be M-A:foreign. > 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 There is no M-A:none, it's M-A:no > to M-A:foreign (or v.v.). It could also be interesting if we ever get stuff > like partial architectures… > > These are all arguments made up after the fact through. The real reason > for APT doing it this way is that it comes natural out of the > implementation. Doing it differently would be an enormous pain² so > I never even considered that another way of interpreting it might exist > until my nose got rubbed in it yesterday…. When I tested dose3's multiarch implementation I only tested it against apt because apt has the handy --simulate option. I do not know how to do similar tests with dpkg without needing superuser privileges. Is there a way? How did you compare apt and dpkg's behaviour in this case in practice? > So, unable to find supporting evidence for either case in the few > specifications, I am appealing now to the high court of Multi-Arch. I only see the architecture qualifiers being mentioned in the MultiarchCross spec and also there it's only a tiny paragraph... > ¹ referring to apt-get here in particular, but anything using libapt is > effected. ² implementation-wise in libapt as it's trying to hide all of > multiarch by translating the problem to singlearch with heaps of explicitly > created implicit dependencies and (versioned) provides. Otherwise we would > have had to throw away at least half of the apt ecosystem… This is the same approach that dose3 takes because cudf does not know about architectures at all - much less about multiarch. Thanks for finding this! I wonder how we can get more dependency resolution testing like this to be sure that dpkg, apt and dose3 agree when looking at the same multiarch problem. cheers, josch [1] https://gforge.inria.fr/tracker/index.php?func=detail&aid=18535&group_id=4395&atid=13808
Attachment:
signature.asc
Description: signature