Bug#796660: Binaries in binary packages match the architecture

[Guillem Jover <guillem@debian.org>]

Hi!

On Sat, 2016-12-31 at 19:04:08 -0800, Russ Allbery wrote:
> Florian Weimer <fw@deneb.enyo.de> writes:
> > It seems to me that a requirement is missing from the policy that
> > binaries (DSOs and executables) which are intended to run on the host
> > must be located in a binary package, and the architecture of the
> > binary package must match the DSO/executable architecture.
> 
> > For example, shipping i386 binaries instead of amd64 binaries is not
> > acceptable, even though these programs might run with the default
> > Debian kernel.
> 
> This is a little tricky to phrase, since there are entirely legitimate
> cases where you do want to ship foreign binaries (packages that set up
> cross-compiler environments, for instance, or packages meant to install
> binaries onto auxiliary devices).

Right, although all of these are pretty much subverting the binary
package architecture system. And, well, they are legitimate only
for historical reasons IMO, and I'd make the distinction between
freestanding objects (firmwares, boot loaders, kernels, etc), and
non-freestanding ones (multilib stuff mainly, and any other ugly
stuff, which should be replaced by proper multiarch enabled
cross-compilers and cross-arch dependencies). And I'd say we should
not allow new packages containing the latter.

Related to exactly this, I recently came up and drafted something that
might make it possible to even fix the first kind of packages too:

  <https://wiki.debian.org/Teams/Dpkg/Spec/FreestandingArches>

> But yes, saying that amd64 packages should generally have amd64 binaries
> and that i386 binaries should be installed on amd64 systems using
> foreign-arch packages, not by putting i386 binaries into an amd64 package,
> seems reasonable to say at this point.  (Have we entirely eliminated the
> various pre-multiarch workarounds for this from the archive?)

Unfortunately we still have multilib cruft around, and packages are
even picking those up anew (c.f. clang). :(

Thanks,
Guillem