Background

See http://lists.debian.org/debian-perl/2012/12/msg00000.html

Motivation

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:

Observations

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.