[continued from previous message]
* Following from the previous, callers that expected a single entry on output,
should not suddenly get multiple when specifying a single package name,
that's why those require specific arch-qualified package names.
* The immediate output should be usable even after the system has been
cross-graded, so it should be resistant to native-arch switch.
Out of scope
------------
The following are implementation and/or distribution specific, and as the spec should ideally be distribution-neutral it should not encode packaging policy. Perhaps it should still be expanded as an implementation or examples
sub-section, and marked as such.
* TODO: Describe compiler and dpkg-shlibdeps search paths.
* TODO: Packaging changes required to make a package multi-arch compliant;
lib, lib-dev, tool, etc.
Unresolved problems
-------------------
* Interpreter problem.
https://wiki.debian.org/Multiarch/InterpreterProposal
https://lists.debian.org/debian-perl/2012/12/msg00000.html
* Co-installable packages for executables.
One possible solution to this might be to use alternatives with priorities
determined dynamically at installation time.
* Runnable architecture attribute.
Sometimes we need to know whether an architecture is runnable or not,
as this is relevant when deciding what to install into the system, and
even though this is of no concern to dpkg directly, it is for high-level
frontends and the user.
* Partial architectures.
https://wiki.debian.org/Teams/Dpkg/Spec/FreestandingArches
* Arch:all packages that can only be built in a specific arch.
https://wiki.debian.org/Teams/Dpkg/Spec/FreestandingArches
* binNMU version skew.
See the “Reference counted files” section.
Can we have a better distinction between the "package" as part of a dependency
and the actual package that gets installed? If I write:
Depends: awk
Calling awk a "package" would be wrong. There is no such package. The string "awk" is a dependency and not a package. The dependency gets satisfied by the provider of the dependency which then is a package. This gets especially confusing in the tables where you write "pkg:any" and without a bit of concentration it's hard to remember whether you mean a dependency annotated with :any or an arch:any package.
In dose3 we use the term vpkg for the terms in a dependency field. Does dpkg or
debian policy have a similar terminology that is not "package"?
I guess this is biased in a dpkg-centric way, where all "packages"
found, be them real instances from the status file, or from any
dependency field, are considered as packages. Whether a package is
virtual (pure or not) depends only on what "packages" are listed in
Provides fields. dpkg internally distinguishes packages as being
"informative" or not.
But will try to see how to make this more clear.
I'm attaching the incremental quick revision I did on top of the
current branch.
Thanks,
Guillem
From 70720d1f1414e9c319b89fd83b6ea2cd0f407120 Mon Sep 17 00:00:00 2001
From: Guillem Jover <
guillem@debian.org>
Date: Fri, 18 Nov 2022 00:03:02 +0100
Subject: [PATCH] fixup! doc: Write down the multiarch specification
---
doc/spec/multiarch.txt | 71 ++++++++++++++++++++++++------------------
1 file changed, 41 insertions(+), 30 deletions(-)
diff --git a/doc/spec/multiarch.txt b/doc/spec/multiarch.txt
index 6fa7ec8c5..4c7ccbc6d 100644
--- a/doc/spec/multiarch.txt
+++ b/doc/spec/multiarch.txt
@@ -3,13 +3,13 @@ Multiarch Specification
Status: implemented, stable
-This specification is considered to be the canonical reference for multiarch, -but in case of discrepancies between this and the current implementation in -dpkg, the latter should be considered the expected behavior, unless it can
-be argued that it is suboptimal and it can be easily changed.
-
-Those discrepancies might come about because this document was rewritten
-from scratch after the fact.
+This specification is considered to be the canonical reference for multiarch +in dpkg, but in case of discrepancies between this specification and the +current implementation in dpkg, the latter should be considered the expected +behavior, unle