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? 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. 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' … 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? 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… 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… 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…. So, unable to find supporting evidence for either case in the few specifications, I am appealing now to the high court of Multi-Arch. Best regards David Kalnischkies ¹ 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…
Attachment:
signature.asc
Description: Digital signature