Hi, On Tue, Dec 09, 2014 at 04:59:29PM +1000, Russell Stuart wrote: > apt_pkg.Dependency objects returned by apt_pkg.Version.depends_list > select a apt_pkg.Dependency.target_pkg that has the same architecture > as the apt_pkg.Version that generated it (Architecture: all packages > aside). Usually this is the right thing do to. > > The one time is isn't is when target_pkg is "multi-arch: Foreign". > In that case you always want the native package, if it is available.
The problem is that a package has no Multi-Arch state. Versions can be marked as foreign, same or whatever, but a package is just a collection of versions. Beside from compatibility concerns (old clients might be confused) it is also wrong from an architectual point of view: A dependency usually is declared on a package in the same architecture space, so that is the safest bet. Other versions of this Debian package from other architectures might or might not provide the same, but we can't know that beforehand and we certaintly can't safely assume that for all versions from this architecture (aka: what would be the result for packages which change from M-A: none to M-A:foreign or vice versa). You might have noticed that I said "provides" in the paragraph above and that is in fact what is happening here: An M-A:foreign package is internally mapped as a (versioned) provides, which on one hand is a giant hack, but on the other hand I am increadibly proud of it as this helps tremendously in making M-A:foreign "just work" even for old clients which have never heard of M-A. The takeaway for you is that at the point where you evaluate which package you are going to install/upgrade to resolve a dependency you can tune your evaluation function to consider the architecture. That is how apt is doing it for example: It puts the candidate version (if any) of the target package as well as every candidate version (if any) of the packages providing the target package (if any) in a list and then sorts the list considering various properties (see CompareProviders here: [0]) to pick the best provider, which for M-A:foreign packages happens to be the one from the native architecture, but there are other things to consider as well (which got added over time. This started very innocently with just priorities…). Now that it does far more than trivial stuff, I could imagine exporting this in some way, which this bugreport is actually asking for, but that needs time for someone to think about a sane API… any takers (after jessie) ? (My fear is that this would otherwise end up looking like the horrible car accidents called DepIterator::*Target* methods we currently have…) Best regards David Kalnischkies [0] https://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/depcache.cc#n956
signature.asc
Description: Digital signature
