Home My Page Projects Dose: library and tools
Summary Activity Tracker Lists SCM Files

[#20844] Essential packages of foreign architectures are considered

2016-10-06 08:44
Submitted by:
Johannes Schauer (josch)
Assigned to:
Nobody (None)
Essential packages of foreign architectures are considered

Detailed description
Consider the following Packages file:

Package: foo
Architecture: amd64
Version: 1

Package: bar
Essential: yes
Architecture: armel
Version: 1

Package: bar
Essential: yes
Architecture: amd64
Version: 1

And now run:

dose-distcheck --deb-native-arch=amd64 --deb-foreign-archs=armel --explain --successes --failures --checkonly=foo:amd64 deb://Packages
output-version: 1.2
native-architecture: amd64
foreign-architecture: armel
package: foo
version: 1
architecture: amd64
status: ok
package: foo
version: 1
architecture: amd64
package: bar
version: 1
architecture: armel
essential: true

background-packages: 2
foreground-packages: 1
total-packages: 3
broken-packages: 0

As you can see, "bar" is part of the installation set in architecture "armel". The problem is the same independent of whether the package "bar" also exists for the native architecture (amd64) as it is the case in this example. Indeed even when ordering the stanzas in the input Packages file such that the amd64 version and armel version of bar are switched, the armel version is still chosen.

The right thing to do, would be to only consider Essential:yes packages of the native architecture. Essential:yes packages of a foreign architecture should not be able to satisfy the implicit dependency of all packages on the Essential:yes set.
Message  ↓
Date: 2016-10-06 12:30
Sender: Johannes Schauer

This problem is actually a bit more complex...

Firstly, since multiarch is not in Debian policy, there is actually nothing that talks about which architecture the installed Essential:yes packages must have.

Secondly, while it might make sense to restrict the package selection to those of the native architecture, this then effectively forbids cross grading from one architecture to another.

Indeed, the "problem" of dose3 choosing Essential:yes packages of the foreign architecture is a similar one to it choosing foreign architecture Multi-Arch:foreign packages to satisfy dependencies. The problem with both is, that the foreign architecture binaries can most likely not be executed on the platform and thus the generated installation set is non-sensical. On the other hand, a system might have more than one architecture that it can execute, either because the CPU can execute more than one instruction set (i386/amd64) or because of binfmt-support and qemu-user-static executables. And in the latter case, installation set with Essential:yes and Multi-Arch:foreign packages from the foreign architecture are completely fine.

So the problem boils down to dose3 (and neither dpkg nor apt) not knowing which architectures can actually be *run*. Once such a system is in place, dose3 could easily decide which Essential:yes and Multi-Arch:foreign to install. Until that is the case, the following filter has to be applied to all foreign architecture Packages files that contain binaries of an architecture that cannot be executed:

grep-dctrl --exact-match \( --not --field=Architecture all --and --not --field=Multi-Arch foreign --and --not --fieldEssential yes \)

In conclusion:

The current behaviour of dose3 generates installation sets involving foreign architecture Essential:yes packages which are nonsensical in most situations. But 1) there is a workaround for this problem (see the grep-dctrl invocation above) 2) the workaround has to be applied anyways to not let dose3 select the wrong M-A:foreing packages, so there is actually no overhead 3) there are some cases where it makes sense for dose3 to behave as it does (the cross-grading situation) and 4) the real fix to this problem (which would also solve the M-A:foreign problem) would be a concept of *runnable* architectures which doesn't exist yet.

Changing the existing behaviour of dose3 would make it impossible to use it for cases where more than one architecture can be executed and in contrast to the existing behaviour, there would be no workaround as it exists for the current behaviour. Thus, I guess until a concept of runnable architectures is introduced into Debian multiarch land, the current dose3 behaviour as it is is preferrable. Thus reducing this bug to the lowest priority.

In any case, here is a patch which would force Essential:yes packages to only come from the native architecture:

--- a/deb/debcudf.ml
+++ b/deb/debcudf.ml
@@ -181,7 +181,10 @@ let init_tables ?(options=default_options) ?(step=1) ?(versionlist=[]) pkglist =
let ivt = init_versions_table tables temp_versions_table in
let iut = init_unit_table tables in
let iet pkg =
- if not options.ignore_essential && pkg#essential then
+ if not options.ignore_essential && pkg#essential
+ && (not (Option.is_some options.native)
+ || (Option.get options.native) = pkg#architecture
+ || pkg#architecture = "all") then
CudfAdd.add_to_package_list tables.essential_table (pkg#name) pkg
List.iter (fun v -> add_pairs temp_versions_table (v,"")) versionlist;

Field Old Value Date By
priority42016-10-06 12:30josch