Bug#749826: Documenting `Multi-Arch: foreign`
On Sat, 02 Sep 2017 at 08:44:14 -0700, Sean Whitton wrote:
> On Sun, Aug 20 2017, Helmut Grohne wrote:
> > A common theme with such cases is to resort to `Multi-Arch: allowed`
> > (e.g. make), but that has the downside of requiring most consumers to
> > attach the :any annotation and that it can never be switched back
> > (because :any dependencies on packages not marked M-A:allowed are
> > unsatisfiable).
That seems like it might be a bug (or design flaw if you prefer). If a
package (build-)depends on foo:any, it is saying "I am only using the
arch-indep parts of foo's interface", whatever those are.
Perhaps a dependency on foo:any by (for example) bar:mips should
always be satisfiable by foo:mips (as though the :any had been omitted),
regardless of foo's multi-arch status? This would bring it back to the
same meaning as omitting the :any, in the trivial case where only one
architecture is enabled.
Perhaps a dependency on foo:any should always be satisfiable by foo:all,
regardless of foo's multi-arch status? (which must be either no or
foreign in this case I think)
Perhaps a dependency on foo:any should be satisfiable by any instance
of foo that is Multi-Arch: foreign? (In this case the :any is completely
redundant, because foreign sets up a similar situation from the other end)
> > * If there is such a conflict, but the relevant packages are not
> > coinstallable due to package relations, is that ok? Example: libc6
> > has such a conflict on /lib/ld.so.1 for mips and mipsel.
> > (Presently, you get an unpack error here.)
>
> If libc6's use is legitimate then it seems we'd need to include this as
> an exception.
libc6's use is mandated by the distro-independent mips* ABIs, so we
can't avoid it (unless we are willing to make binaries built on
Debian mips unusable on other distros, including older Debian, by
defining a Debian-specific ELF interpreter like
/lib/mips-linux-gnu/ld.so.1).
> > I think "the files installed by ``Architecture: all`` packages always
> > provide architecture-independent interfaces." is too broad. The counter
> > example is haskell-devscripts-minimal. This needs to be weakened
> > somehow.
I would argue that these interfaces are architecture-independent from
the perspective of the package's (lack of) architecture. What they
are not independent of is the *build machine* architecture, just like
running uname -m or inspecting /proc/cpuinfo aren't independent of the
build machine architecture. This is certainly a problem for
cross-compilation, but it isn't the same issue as in dpkg or pkg-config,
where the architecture for which dpkg or pkg-config was built gets
hard-coded into its installed files (as the output of --print-architecture
or part of the default search path, respectively).
> > For instance, the policy should make it
> > clear that marking libmdds-dev `Multi-Arch: foreign` (fictional, see
> > #843023) would be a policy violation.
It is not clear to me that doing so *should* be a policy violation. If
libmdds-dev contains only headers (no shared or static library), and it
exposes architecture-independent libboost-dev headers (but no Boost
shared or static library), is there really anything wrong with having
libboost-dev from "the wrong architecture"?
S
Reply to: