This page contains design decision rationales that are not listed in specifications or package documentation. For other multiarch topics, see the multiarch category.
This page should eventually be folded into the multiarch.txt that will be added to dpkg, and to debian-policy, so a compatible license is expected. That would be GPL-2+, if you don't agree with that please avoid making modifications to this page.
Contents
-
Overarching rationale
- Why are arch:all packages treated implicitly like arch:native?
- Why not adopt the interpreter proposal?
- Why are :any qualified dependencies only satisfied by M-A:allowed packages?
- Why do M-A:foreign packages not satisfy :native qualified dependencies in build-dependencies?
- Why are arch:all packages in build dependencies not implicitly treated as M-A:foreign in Debian?
Overarching rationale
The main theme among many of the following rationale entries is that backwards semantics should be preserved, and that using a packaged manager that does not support multiarch semantics (barring the arch-qualified syntax) should operate in the same way. This implies that a flag-day should never be required, ever.
Why are arch:all packages treated implicitly like arch:native?
(Context: arch:all packages have a dual nature, they represent packages that supposedly share their contents across all actual architectures (and as such help reducing archive duplication), and they represent packages with code that is architecture independent. But those meanings are not always true, and sometimes packages with only one of the meanings is used just out of convenience.)
It was thus considered that not all arch:all packages are truly architecture independent (see above), and might have architecture-specific assumptions in their code. Because the fact that the code is the same across multiple architectures does not imply that it works everywhere. The same applies to data, some is endian-specific. It was deemed better to require marking them explicitly so that we would preserve backwards semantics.
It was also considered that allowing to treat arch:all packages as truly architecture independent could cause resolvers to pull in undesirable mixes of arch:any packages which might not be even runnable on the local system. Because the arch:all boundaries in dependencies break the knowledge of the architecture chains (which should really not be a problem, except in the multiarch interpreter problem).
Pros:
- Preserve backwards compatibility.
- Avoid arch-tentacled accidental dependency installations.
Cons:
- Makes many situations more difficult than necessary.
Suggested change:
Why not adopt the interpreter proposal?
- Configuring arch:all packages multiple times (for multiple architectures, like m-a:same) is a backwards compatibility break. It needs packages declaring support for this. No metadata scheme for this is developed thus far.
- If dpkg is supposed to automatically configure/deconfigure arch:all packages as necessary, it effectively gains a full blown resolver. Thus far dpkg has always looked at dependency problems locally, so this means a significant departure from the current assumptions in the code.
- If dpkg is not supposed to automatically configure/deconfigure arch:all packages, then there needs to be a dpkg user interface for doing so. Having to manually change configuration status for packages may be a significant burden to users.
Why are :any qualified dependencies only satisfied by M-A:allowed packages?
This kind of relationship was added in part so that packages could not start declaring wildcard relationship without cooperation and agreement from the packages providing such interfaces, because the semantics of this interfaces might not be clear to external parties.
Why do M-A:foreign packages not satisfy :native qualified dependencies in build-dependencies?
Pros:
- This is in theory a nonsensical relationship. The interfaces in the package are either architecture independent or not.
- It was also intended to be used as a detector of such situations, so that they could be corrected.
Cons:
- This makes transitions more difficult, or differing metadata on different suites can cause FTBFS scenarios.
Why are arch:all packages in build dependencies not implicitly treated as M-A:foreign in Debian?
- Build dependencies should be no different than dependencies in this regard.
Even packages with bit-by-bit identical content can do different things on different architectures. Example is a shell script that calls uname -m.
Existing examples for arch:all packages cannot be M-A:foreign: 669188, 769377, 769379
- In those cases where arch:all cannot mean M-A:foreign, we would not be able to fix that
More arguments and examples of Architecture:all packages that cannot be M-A:foreign can be found in 666772