Hi, Quoting David Kalnischkies (2015-04-18 17:24:45) > On Fri, Apr 17, 2015 at 03:39:14PM +0200, Johannes Schauer wrote: > > no because different packages might provide "bar" and "bar:amd64". So even > > on amd64 this dependency might be resolved differently. > > huh? Can you give an example? > > My point of view here is that there isn't a difference between reading > "bar" and "bar:amd64" while parsing the dependencies of an amd64 > package. As long as you don't give the ":amd64" a 'special' meaning of > course, which was the previous question. you are right, the dependencies "bar" and "bar:amd64" are equivalent if the package having them is amd64 as well. I should've tried giving an example for my claim when I made it to discover I was wrong before causing confusion. > > 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. > > What about a package blub2:i386 which Provides: bar ? Isn't that > providing bar:i386 as well, because that is what bar stands for… ? > On the other hand blub2:amd64 which 'Provides: bar' isn't providing > bar:i386 (but bar:amd64), which was the topic of a previous mail [0] > from me to the list which while not generating a response, at least > dpkg seems to agree with me now on that one (now, future unknown, the > associated bugs are still open in dpkg and apt). The deb-control(5) man page in dpkg git says that all Provides: are implicitly :any if no architecture qualifier is explicitly given: http://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/man/deb-control.5#n264 So if I read this right, then a package blub2:amd64 which Provides:bar also implicitly provides bar:i386. This doesn't seem right if blub2 is not M-A:foreign. > > How did you compare apt and dpkg's behaviour in this case in practice? > > Discussed off-list as its slightly off-topic here. > > But for completeness in short: APT has a battery of shellscripts we > dubbed integration tests, which can among other things build packages > and (try to) install them via apt with dpkg as non-root in a temp directory. You in IRC and the scripts were a great help, thank you! I'm currently writing a test suite to compare the behaviour of dpkg, apt and dose3 for all possible combinations of two packages with different architectures, multiarch properties, depends, provides and conflicts, leading to 7744 test cases. After having solved a remaining dpkg weirdness (why do the last two dpkg calls in this script [1] do different things??) I'll cross post my findings to these lists under a new topic. cheers, josch [1] http://paste.debian.net/167504/
Attachment:
signature.asc
Description: signature