Bug#749826: Documenting `Multi-Arch: foreign`
On Sat, Sep 02, 2017 at 08:44:14AM -0700, Sean Whitton wrote:
> Rather than introduce the new terminology 'intended interface', which we
> would definitely have to define, how about something like this:
>
> If all a package's architecture-dependent interfaces are listed in
> README.multiarch, the package is not considered to have any
> architecture-dependent interfaces for the purposes of determining
> whether it may be labelled Multi-Arch: foreign.
This is not how it works. It's not like you can just mark any package
Multi-Arch: foreign after saying that it is architecture-dependent. That
documentation must come with a contract saying that reverse dependencies
must not use those architecture-dependent interfaces.
> If libc6's use is legitimate then it seems we'd need to include this as
> an exception.
Well, it's not exactly legitimate. It's more like unavoidable as Simon
pointed out in his reply. Technically, libc6's behaviour is wrong and
causes unpack errors. The reasonable solution would be prohibiting
coinstallation of libc6:mips and libc6:mipsel, but package metadata does
not allow us to do that currently (#747261 -> self-conflicts are always
ignored). The other option of removing Multi-Arch: same from libc6 would
essentially render Multi-Arch useless. So all we can do now is pretend
the issue wasn't there.
> > * If you rebuild the source package with a very different
> > installation set (i.e. much newer Build-Depends), does it still
> > have to match with older instances? Example: #825146. What
> > divergence in installation sets is ok?
>
> We could just say that it must match the instances in the target suite.
We could. That would render libgiac0 rc buggy for instance, because it
was built on mips64el three weeks later than on other architectures and
thus uses an incompatible gettext.
That definition is pretty annoying for bootstraps though as replicating
ancient toolchain is kinda the opposite of what bootstrappers do.
> > (A simple way to satisfy this requirement is to use
> > architecture-dependent paths exclusively. That works except for
> > /usr/share/doc/$pkg.)
> >
> > * The maintainer scripts must handle multiple configuration and
> > multiple deconfiguration correctly. In particular, a package can be
> > purged for one architecture while being installed for another.
> > Example: #682420.
> >
> > (A simple way to satisfy this requirement is to not ship maintainer
> > scripts.)
> >
> > * Source packages carrying any binary package marked `Multi-Arch: same`
> > must always be binNMUed in lock-step. (Presently violated e.g. by
> > libselinux1)
>
> Could you turn this into some commits against my branch, please?
I tried and ran into a new problem: I am now convinced that we cannot
just describe one Multi-Arch value after another as they do share some
common values. That "interface" aspect and architecture-constraints on
dependencies is a common theme and likely deserves an introductory text.
Yet, I am attaching what I have.
> It sounds like we need to just drop the whole bullet point.
> Architecture: all packages need to be checked carefully, just like
> Architecture: any packages.
Reworded.
> To my mind, the most important ways to achieve readability in this case
> are
>
> - avoid repetition
> - avoid "probably", "likely" sentences.
The latter is particularly hard, because we violate the strict
definitions more often than is immediately apparent.
As Simon's mail demonstrates, we likely need more answers/consensus
before continuing. I'll reply in a separate mail.
Helmut
diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 509a96e..e6451d5 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -1028,6 +1028,18 @@ control file.
We consider the meaning of each possible value of this field
separately.
+``Multi-Arch: no``
+++++++++++++++++++
+
+This value is the default. When satisfying a dependency on a package
+(implicitly) marked ``Multi-Arch: no``, the depender and the dependee
+must have the same architecture. For the purpose of this matching,
+``Architecture: all`` packages are treated as if they had the
+architecture value of ``dpkg``.
+
+The value ``no`` cannot currently be used in binary packages due to
+limitations of the archive processing.
+
``Multi-Arch: foreign``
+++++++++++++++++++++++
@@ -1037,12 +1049,15 @@ architecture.
In order to determine whether this holds, you should consider
the files installed by the package
- ``Architecture: all`` packages always provide
- architecture-independent interfaces. Shared and static libraries
- provide architecture-dependent ABIs. Binary executables may
- provide architecture-independent interfaces: could software
- interacting with the executable determine the architecture for
- which it was built without reading the executable file?
+ ``Architecture: all`` packages tend to provide
+ architecture-independent interfaces, but they can expose
+ architecture by calling into other packages (e.g. ``dpkg
+ --print-architecture``, ``uname`` or parsing ``/proc/cpuinfo``).
+ Shared and static libraries provide architecture-dependent ABIs.
+ Binary executables may provide architecture-independent interfaces:
+ could software interacting with the executable determine the
+ architecture for which it was built without reading the executable
+ file?
maintainer scripts and triggers
These may generate architecture-dependent interfaces, such as by
@@ -1050,11 +1065,13 @@ maintainer scripts and triggers
the dependencies of a package
A package may expose architecture-dependent interfaces of other
- packages by depending on them, or by implicitly depending on
- ``Essential: yes`` functionality. Good examples are empty binary
- packages that exist simply to cause other packages to be installed
- (these are used when renaming a binary package, and are known as
- transitional packages).
+ packages by depending on them. By using other packages (even
+ essential ones), their architecture awareness may be exposed. Shared
+ libraries are generally considered implementation detail and thus do
+ not contribute to the interfaces of a package.
+
+If in doubt, the intended interfaces should be described in a file
+``debian/README.multiarch``.
.. _s5.7:
Reply to: