[15372] in athena10
Re: [Debathena] #1594: Set Multi-Arch: foreign on all Architecture:
daemon@ATHENA.MIT.EDU (Debathena Trac)
Sat Jan 27 19:28:53 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:28:29 -0000
Reply-To:
Message-ID: <057.22d4975191f43c5277025cf2ff2dbc56@mit.edu>
In-Reply-To: <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: -- | Resolution:
Keywords: | Fixed in version:
Upstream bug: |
------------------------------+---------------------------------------
Description changed by geofft:
Old description:
> 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.
New description:
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 [https://wiki.debian.org/MultiArch/Hints
#set_Multi-Arch:_foreign MultiArch/Hints "set Multi-Arch: foreign"] on the
Debian wiki, 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#comment:1>
Debathena <http://debathena.mit.edu>
MIT Debathena Project
