On Fri, Apr 17, 2015 at 03:39:14PM +0200, Johannes Schauer wrote: > > 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. 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. > > (, "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? (Slightly embarrassed) Yes, but not as a feature, but as a "I haven't taken explicit measures to prevent it". Neither is legal in dependencies, native is legal in build-dependencies through. That was meant as a reminder that amd64 is the native architecture in this example and that architecture all is mapped to the native architecture as well. Not as a valid specifier showcase, sorry… > >) 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. 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). > > 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. The 'problem' spawning these questions is debugsymbol packages which do depend on the package they provide debugsymbols for. Installing debugsymbols for the wrong architecture isn't dangerous, but it is also quite useless and its quite clear that a M-A:foreign doesn't apply here. I guess instead of worrying about this usecase too much, we might be better of not using a depends here at all. Potentially we are way better of with 'foo-dbg enhances libfoo0, foo' and a 'apt-get debugsymbols foo' grabbing -dbg packages enhancing foo (and potentially optionally the same for its dependencies. Finding a good cut-off point might be hard through… mhhh…) similar to how 'apt-get source foo' grabs the source for the package foo. (in any case, not really the topic of this thread, will move that where it belongs instead) > > 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 Damn. Always the same mistake. (Hey brain, you can even save two keystrokes here, do you realize that…) > > 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? 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. Best regards David Kalnischkies [0] https://lists.alioth.debian.org/pipermail/multiarch-devel/2014-November/000098.html
Attachment:
signature.asc
Description: Digital signature