Hi Gustavo, I have attached a small testcase which setups up an environment as you seem to describe it (runable if you drop it into apt/test/integration). "Unfortunately" the script has the expected output, so I suspect I have misunderstood you, which, given that many terms in MultiArch are overloaded isn't exactly hard, so don't worry, your bugreport is fine. :) I will still comment on the two cases, even if I am wrong though: On Sat, Sep 14, 2013 at 8:19 AM, Gustavo Prado Alkmim <alkmim@ic.unicamp.br> wrote: > First case: I was trying to crossbuild a source package A that build-depends > package B:armhf where the build architecture is amd64 and the host > architecture is armhf. Package B is multiarch: foreign. Apt install package > B:armhf instead of B:amd64 even B being a multiarch: foreign package. IMHO, apt > should install B:amd64 to solve the build-dependencies instead of B:armhf. The explicit mentioning of an architecture is only for special cases and in those special cases they should overrule the 'normal' behavior. Why are you build-depending explicitly on a B:armhf if any B would do otherwise? > Second case: I was trying to crossbuild a source package A that build-depends > package B:any that depends package C:all where the build architecture is amd64 > and the host architecture is armhf. Package B is multiarch: same and Package C > is multiarch: foreign. Apt fails to solve the dependencies because it tries to > install package C:armhf instead of Package C:all which is a multiarch: foreign > package. IMHO, apt should install Package C:all without returning error. As the script shows, I can't reproduce this. Note that arch:all packages are currently interpreted as being arch:any (which are only available for your native architecture) by design. It tends to confuse people, but was needed for transition reasons. (There are discussions ongoing to resolve a few issues with that though.) Best regards David Kalnischkies
Attachment:
test-bug-722880
Description: Binary data