Quoting Hugh McMaster (2017-10-23 14:11:55) > On Monday, 23 October 2017 5:07 AM, Helmut Grohne wrote: > > They kinda are duplicates, but unless the markupsafe dependency is > > demoted, the advice from #875650 to add m-a:foreign is simply wrong. > > Since #769380 contains all the deatils, I am simply closing the newer > > bug. > In what way? Marking M-A: foreign satisfies the build-dependencies I need. > Otherwise, I have to deal with python3-mako:i386 not found.
Marking a package as M-A:foreign has a special meaning just as Depends:foo has a special meaning. And if certain conditions are not met, you would also not add a Depends:foo because it would be wrong. The same goes for Multiarch markings. Sure, we could make everything in the archive M-A:foreign and as far as dependency satisfaction goes we would not have any problems anymore because everything would be satisfied. But then problems would arise once the contents of a package are actually used by executing them for example. So we can only mark those packages M-A:foreign that meet certain criteria. For M-A:foreign this means that the package must not expose an architecture specific interface. What constitutes such an interface can sometimes be very subtle but in this case the situation is clear and it was already explained by Helmut in an earlier Email: On Fri, 21 Nov 2014 10:41:03 +0100 Helmut Grohne <[email protected]> wrote: | Adding M-A:foreign is wrong. Suppose you are trying to satisfy | python-mako:i386 on a system that is natively amd64. Then python-mako | would satisfy this dependency and use python-markupsafe:amd64 in its | installation set. However when importing modules in an embedded i386 | python interpreter an ImportError would be raised, because | python-markupsafe is unavailable. Thus python-mako exposes the | architecture awareness of python-markupsafe and cannot become | M-A:foreign. Thanks! cheers, josch
signature.asc
Description: signature
