Groups | Search | Server Info | Login | Register

Groups > linux.debian.bugs.dist > #1239677

Bug#749826: Documenting `Multi-Arch: foreign`

Cross-posted to 2 groups.

Show all headers | View raw

Hi,

I'm an interested party, but certainly no expert on this topic. I 
have however a few editorial remarks, inline below.

* Helmut Grohne <helmut@subdivi.de> [250329 12:39]:
>diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
>index 3151816..d43acac 100644
>--- a/policy/ch-controlfields.rst
>+++ b/policy/ch-controlfields.rst
>@@ -1307,6 +1307,150 @@ This list is intentionally incomplete. You should consult the
> documentation of the tool or package in question for which keywords it
> defines and when they are needed.
> 
>+.. _s-f-Multi-Arch:
>+
>+``Multi-Arch``
>+~~~~~~~~~~~~~~
>+
>+A Debian installation may combine packages from multiple architectures.
>+The ``Multi-Arch`` header enables individual packages to declare their
>+support for this feature. It may occur only in the control file of a
>+binary package or in the per-package fields paragraph of a source
>+package control file. The semantics of permitted values are ``no``
>+(default), ``foreign``, ``same`` and ``allowed`` as described
>+individually.
>+
>+.. _s-f-Multi-Arch-no:
>+
>+``Multi-Arch: no``
>+^^^^^^^^^^^^^^^^^^
>+
>+When satisfying a dependency (using ``Depends``, ``Pre-Depends``,
>+``Provides``, ``Recommends``, or ``Suggests``), the architecture of the
>+depender and the architecture of the dependee being thus marked are
>+required to be equal. For negative dependency relations (``Breaks``,
>+``Conflicts``, and ``Replaces``) the architecture does not have to match
>+for the relation to take effect.  Architecture-independent packages are
>+treated as if they had the architecture value of the installed `dpkg`
>+package.  Furthermore, multiple instances of a package with the same
>+name and different architectures are not considered coinstallable.
>+
>+Note that due to limitations in the archive management software, this
>+value cannot currently be specified explicitly in binary package control
>+files.

The last paragraph here is a bit confusing. I think the text should 
reiterate that "no" is the implicit default.

>+
>+``Multi-Arch: foreign``
>+^^^^^^^^^^^^^^^^^^^^^^^
>+
>+A binary package may be marked with a ``Multi-Arch: foreign`` control
>+header if the provided interfaces are independent of the architecture of

This could also say:
  +A binary package may be marked ``Multi-Arch: foreign`` if the provided
...
with no loss of meaning.


>+the package. Any provided virtual packages (see :ref:`s-virtual`)
>+inherit this property. Given this header value, dependencies on this
>+package are considered satisfied even when the depender's architecture
>+differs from the marked package.
>+
>+There are five main areas that can contribute to the interface of a
>+package and if any of them provides an architecture-dependent interface,
>+a package must not be marked with ``Multi-Arch: foreign``.
>+
>+- The installed files of a package: Architecture-dependent packages may
>+  install different sets of files or files with different content for
>+  multiple architectures and these differences may contribute to the
>+  interface (e.g. an endianess-dependent database file).  For
>+  architecture-independent binary packages, there is aspect does not

s/there is/this/

>+  apply.
>+
>+- The behavior of installed files of a package: When interfacing with
>+  installed files by executing them, their behavior may contribute to
>+  the provided interface.  For instance, interfacing with shared and
>+  static libraries necessarily is architecture-dependent.  Whilst binary
>+  executables generally differ with architectures, the exposed interface
>+  (for example the command line interface, the content on standard
>+  input/output, the way they process files) may be independent of the
>+  architecture used to execute.  In that case, their interface may be
>+  considered architecture-independent.
>+
>+- Maintainer scripts and triggers: A package may behave in an
>+  architecture dependent way, when the maintainer scripts or invoked
>+  triggers behave differently on different architectures. For instance,
>+  byte-compiling source files into architecture-dependent bytecode
>+  during ``postinst`` may turn the interface of a package
>+  architecture-dependent.
>+
>+- The dependencies of a package: A package may expose functionality of
>+  other packages by depending on them. In general, an executable does
>+  not expose its linked shared libraries and therefore they do not
>+  usually contribute to the interface.

How about:
                                          Usually, an executable does
     not expose linked shared libraries as its interface, and thus 
     they should not be considered contributing to the package 
     interface.


>+                                       On the other hand, the whole
>+  point of transitional packages is to expose such functionality.
>+  Likewise, development packages for shared libraries necessarily expose
>+  their own dependencies.

  +  their own dependencies as the package interface.
?

>+
>+- Implicit and foreign dependencies of a package: Essential packages are
>+  implicitly depended upon and need not show up in ``Depends``. Yet
>+  their behaviour can be architecture-dependent. For instance, using
>+  ``dpkg --print-architecture`` can be used to emit the native
>+  architecture even though ``dpkg`` is marked ``Multi-Arch: foreign``.
>+  Similarly, calling ``pkgconf`` (without a prefix) will behave
>+  differently on different architectures as its search path is
>+  architecture-dependent even though ``pkgconf-bin`` is considered
>+  ``Multi-Arch: foreign``.
>+
>+The interfaces of a package are determined by its maintainer.  However,
>+some packages might expose architecture dependencies when other packages
>+use them in a manner not intended by the maintainer.  This can happen
>+when it is not clear which parts of the package are its interfaces.
>+
>+In such cases, where the package satisfies the criterion for
>+``Multi-Arch: foreign`` but might expose architecture dependency,


  +``Multi-Arch: foreign`` but might expose an architecture-specific dependency,
?

>+because it is not clear which parts of the package are its interfaces,
>+the interfaces of the package should be described in the file
>+``debian/README.multiarch``.

I assume this implies: "in the source package"

>+
>+Conversely, justifying the use of functionality that is not covered by
>+its offered interface with a dependency on such a package is not
>+allowed.
>+
>+``Multi-Arch: same``
>+^^^^^^^^^^^^^^^^^^^^
>+
>+Multiple binary packages with the same name and version may be installed
>+concurrently if all of them carry this header valued ``same``. Any set
>+of packages with matching name and version being thus marked must
>+support two properties.

  +support the following properties:

>+
>+- All filenames that are present in multiple of these packages must
>+  contain bit-identical content across architectures. [#]_
>+
>+  For files whose name is unique within this set, no such requirement
>+  exists. Therefore, such packages usually install most of their files
>+  below ``/usr/lib/${DEB_HOST_MULTIARCH}``.
>+
>+- The maintainer scripts must be prepared to be configured or
>+  deconfigured multiple times. In particular, ``postrm`` must consider
>+  that another instance may still be present. It may check the
>+  ``DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT`` environment variable set by
>+  ``dpkg``.

Two thoughts:

1) is DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT documented in policy? 
Immediate question: is it 0- or 1-based, and is it in-/decremented 
before or after the maintscripts run?

2) should something be said about arch-specific changelog files?

>+
>+``Multi-Arch: allowed``
>+^^^^^^^^^^^^^^^^^^^^^^^
>+
>+A package annotated this way behaves as if it were annotated with the

s/annotated/marked/ for consistency?

>+``no`` value except that a depender may now append ``:any`` to the
>+package name in a dependency relation field. In that case, the
>+dependency is considered satisfied even when the architecture of the
>+depender differs from the dependee's. Dependencies carrying a ``:any``
                                                               an (?)

>+suffix can only be satisfied by packages marked ``Multi-Arch: allowed``.
>+
>+This value should be used rarely for cases where the package can be used
>+in an architecture-dependent way or in an architecture-independent way
>+and the decision of which applies is deferred to the depender. The most
>+common use is with programming language interpreters that enable loading
>+architecture-dependent plugins.
>+
>+Since removing this value tends to break reverse dependencies that
>+employ ``:any``, uses of it should be discussed with
>+*debian-devel@lists.debian.org* first.
>+
> .. _s5.7:
> 
> User-defined fields
>@@ -1443,3 +1587,9 @@ details.
> 
> .. [#]
>    That is, the parts which are not the ``.dsc``.
>+
>+.. [#]
>+   As an exception, the ``libc6`` package is marked ``Multi-Arch: same``
>+   despite not fully complying with this requirement, because the
>+   location of the dynamic loader is not universally unique and cannot
>+   be changed without breakig ABI.

Thanks for working on this!

Best,
Chris

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Find similar

Thread

Bug#749826: Documenting `Multi-Arch: foreign` Helmut Grohne <helmut@subdivi.de> - 2025-03-29 12:40 +0100
  Bug#749826: Documenting `Multi-Arch: foreign` Holger Levsen <holger@layer-acht.org> - 2025-03-29 13:20 +0100
  Bug#749826: Documenting `Multi-Arch: foreign` Chris Hofstaedtler <zeha@debian.org> - 2025-03-29 14:10 +0100

csiph-web