The footnote essentially claims that a particular way of resolving dependencies (explained below) is impossible to do with dpkg. Let us assume dpkg not to be a limitation here and see what would happen.
This proposal does not change the syntax of dependencies or anything in control files. It changes the semantics of the current fields in a way, that should not to break existing code.
Rules for resolving dependencies
For each package add a set of actual architectures (i.e. anything but "all" and "any") to the internal data structure of dpkg. In many cases it will be a singleton set and referred to in singular form. For each package compute the set of running architectures as follows:
- Start with the set of actual architectures known to dpkg (dpkg --print-architecture + dpkg --print-foreign-architectures)
- If the package is architecture dependent, intersect with the singleton set of its architecture.
For each dependency, that is not marked as :any and is not a Multi-Arch:foreign package, intersect with the running architectures of that dependency.
For architecture independent packages a dependency can be fulfilled multiple times by architecture dependent packages that are marked with Multi-Arch:same. In this case the intersection is to happen with the union of the running architectures of all instances of the depended upon package.
- If the set of running architectures turns out empty, the dependencies of the package considered are deemed unsatisfied.
For architecture dependent packages the set of running architectures is always a singleton set. Only for architecture independent packages it may contain more than one element. An example exercising this is fakechroot.
Why is it a solution?
See https://lists.debian.org/debian-devel/2013/04/msg00599.html for examples that still work with these slightly changed rules and terminology.
Implementation in dpkg
The set of running architectures would replace or extend the Status field in the dpkg databases' status file. New internal operations need to be added to add or remove architectures from the set of running architectures provided the above rules are met locally. The database does not have to represent the actual running architectures, a subset suffices as an approximation. When installing a package, this approximation may turn a package uninstallable. In this case the running architectures of the depended upon packages need to be reevaluated to see if a new architecture can be added. Similarly when removing a package these new operations must first remove running architectures from reverse dependencies before proceeding the actual package removal. With this approach all changes to the status database remain local and continue even in the event of a partially broken database.