Pin priority 600 on suite can prevent installation of build dependencies in certain circumstances

[JonathonHall-Purism]

debspawn sets the pin priority for the named suite to 600, while others are set to 500: https://github.com/lkhq/debspawn/blob/master/debspawn/osbase.py#L448

Since the pin priorities don't apply during debootstrap, this means it is possible for debootstrap to select packages that will later cause conflicts when apt tries to install build-dependencies. It also means that bootstrapping a container, then updating it later, won't necessarily be the same as an equivalent container bootstrapped now. (Bootstrapping can select packages that apt upgrade will not select.)

This is happening now in PureOS byzantium, we are trying to build util-linux in byzantium-updates-proposed. It works in a container bootstrapped some months ago, but not in one bootstrapped recently. Several binary packages built from the systemd source package are conflicting (they have = <version> deps to the others).

• byzantium has 274.3-7+deb11u5
• byzantium-security has 247.3-7+deb11u6
• byzantium-updates and byzantium-updates-proposed have 247.3-7+ddeb11u4

1. Bootstrapping byzantium-updates-proposed (base suite byzantium, extra suites b-u, b-u-p, b-s) installs ...u6 of libsystemd0 and libudev1.
2. Building util-linux tries to install libsystemd-dev and libudev-dev, which fails because apt selects the ...u4 from b-u-p due to pin priority 600, and that conflicts with the already-installed packages from b-u-p.

An older container on estragon works, because it bootstrapped the ...u4 packages and apt upgrade will not install the ...u6 packages (b-u-p has higher priority). However I can't readily recreate this environment, because debootstrap always picks the newest packages from b-s.

I think (but am not sure) that we shouldn't pin the named suite to 600, it should be 500 like the others. I think here we would want to build util-linux with the newer systemd packages from byzantium-security (but I am not terribly experienced here, would appreciate input).

FWIW, _setup_apt_repo_preferences also says it is "setting all suites to the same priority", which it doesn't actually do. This would seem to align with the intent but I don't know if there was a reason for this priority.

[ximion]

If we do not pin the named suite to a higher priority, the solver will fail to select packages from the respective suite preferentially - in the past, that resulted in octarine packages ending up unbuildable, not getting their dependencies properly resolved to other octarine or -updates packages, or in the worst case we would get packages uploaded to an overlay suite that had been built against stuff in the underlying suite, breaking the dependency chain when the overlay was active.

I'm unsure what the solution is here, I need to look closely at it once again. But it may require some tweaks to APT itself this time (or we need to implement other hacks, like sbuild creating a dummy package for build-dependencies).

[JonathonHall-Purism]

Ah, I figured there was some history like that 🙂 Thanks for taking a look.

Another option might be to bootstrap only with the base suite, then add all the additional suites later and upgrade. I think that would mean that the bootstrap could not select a combination that would conflict with the later apt pinning, since it'd only have one suite available.

I'm not sure either though, looking forward to your expert opinion!

For now I worked around it on estragon and fennel by lowering the pin priority of byzantium-updates-proposed and upgrading, but if this is a bad idea maybe I could bootstrap them again and manually downgrade the packages that were chosen from byzantium-security 🤔