[15371] in athena10
[Debathena] #1594: Set Multi-Arch: foreign on all Architecture: all
daemon@ATHENA.MIT.EDU (Debathena Trac)
Sat Jan 27 19:28:03 2018
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@mit.edu>
Cc: debathena@mit.edu
To: geofft@mit.edu
Date: Sun, 28 Jan 2018 00:27:35 -0000
Reply-To:
Message-ID: <042.9130584a8637b69e17d8a42b805645c3@mit.edu>
Content-Transfer-Encoding: 8bit
#1594: Set Multi-Arch: foreign on all Architecture: all packages
----------------------------------+-----------------------------------
Reporter: geofft | Owner:
Type: defect | Status: new
Priority: insignificant | Milestone: The Distant Future
Component: -- | Keywords:
Fixed in version: | Upstream bug:
----------------------------------+-----------------------------------
There is an edge case where a pre-multiarch `Architecture: all` package
should be considered as for the native architecture only: when it re-
exports an architecture-relevant interface from one of its dependencies.
(For instance, `libatlas-dev` is `Arch: all` because it only includes
headers, and depends on `libblas-dev` which ships the library; someone
installing `libatlas-dev` as a dependency for an amd64 package or a build-
dep for an amd64 build is not going to find `libblas-dev:i386` helpful.)
Because of this edge case, by default, Architecture: all packages are
considered as actually only being installed for the native architecture,
and require all their dependencies to come from the native architecture,
unless you set `Multi-Arch: foreign`. When you do, their dependencies and
reverse-dependencies can come from any architecture, and they can be used
as cross-build-dependencies.
This edge case is not relevant for, I think, any of the Architecture: all
packages in Debathena. In particular it is irrelevant for things like the
major metapackages (debathena-workstation etc.) or for just about any
config package, unless we're doing something weird with compiling binary
files in the postinsts or something.
In practice, for people just using a single arch, it doesn't matter much.
But I think the big case this affects is converting a Debathena machine
in-place from one architecture to another (e.g., i386 to amd64). So long
as `debathena-workstation` isn't `Multi-Arch: all`, the package is broken
unless _all_ of its dependencies are installed from the native
architecture, so switching the machine's native architecture gets a lot
more complicated immediately for no good reason.
See [https://github.com/sipb/config-package-
dev/pull/2#issuecomment-361025694 my comment on config-package-dev#2] and
the links in that PR, notably DebianWiki:Hints#set_Multi-Arch:_foreign,
for more details.
We should in theory go through all `Arch: all` Debathena packages, make
sure they're not doing anything weird with compiling things in postinsts
or depending on arch-specific libraries. (Most Debathena metapackages or
config packages should not care about libraries; those that do, like
debathena-athena-libraries, should be `Architecture: any` anyway so that
you can install both sets of libraries if you want.)
This isn't very high priority, but if something comes up where in-place
architecture switches become relevant, then this will become high-
priority.
--
Ticket URL: <https://athena10.mit.edu/trac/ticket/1594>
Debathena <http://debathena.mit.edu>
MIT Debathena Project
