Quoting Helmut Grohne (2019-03-27 17:22:53) > On Wed, Mar 27, 2019 at 03:24:27PM +0100, Thorsten Glaser wrote: > > Yes, but these are all arch:all already, so unless they have not-arch:all > > dependencies, this ought to work (I really can\u2019t think of a way to > > implement something in arch:all with only arch:all dependencies that > > doesn\u2019t work as M-A:foreign). Testing is likely still appreciated > > \u263b > > I'm kinda tired of debunking this argument, but let me give counter > examples again: > > * locales #669188 > * Package a shell script that calls `uname -m'. Its output will be > architecture dependent even though the package can be arch:all. > + haskell-devscripts do a variant of this. #769377 > + dh-ocaml does a variant of this. #769379 > If this was automatable, we'd do it already. Unfortunately, multiarch is > about interfaces and Debian has a tradition of not explaining what the > interface of a package is. We define the interface by reassigning bugs > back and forth between consumer and provider. We'll be having problems > for as long as we're unclear about interfaces. autopkgtest improves the > situation a little. in this context also bug #666772 comes to mind. It seems the idea that arch:all implies m-a:foreign used to be so common that ubuntu had apt patch to implicitly treat arch:all as m-a:foreign for build dependency resolution. I was about to write something about why arch:all packages are thus treated as being of the native architecture but I see that this wiki page already is doing so for me: https://wiki.debian.org/Multiarch/MissingRationale#Why_are_arch:all_packages_treated_implicitly_like_arch:native.3F I updated this wiki page to explain the rationale a bit better: https://wiki.debian.org/Multiarch/MissingRationale#Why_are_arch:all_packages_in_build_dependencies_not_implicitly_treated_as_M-A:foreign_in_Debian.3F I can understand Helmut getting tired of debunking this argument so how about we make sure that these wiki pages describe the situation in the best way possible so that we can pass it around any time anybody asks. So please point out where anything on this page is unclear. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature