[Impact]
Users who build their own Ubuntu images using debootstrap against Debian metadata that is not generated with alpha-sorted-by-Package-field Packages files will see errors in some cases: debootstrap does not correctly discover all available packages, and so fails to satisfy dependencies which are present. (At the very least, Artifactory's metadata generation is affected.)
[Test Plan]
This bug can be reproduced/confirmed fixed using the autopkgtest included in the backported patch (which can also be found at https://salsa.debian.org/installer-team/debootstrap/-/blob/master/debian/tests/unsorted-packages-files). I will also execute testing against our internal repository (where we've been using this patch for months, with no issue).
[Where problems could occur]
debootstrap could start failing for bootstraps against the Ubuntu archive: this patch is present in newer Ubuntu releases, so this is unlikely. These issues would also be caught before impacting users.
For users who are bootstrapping against their own repository which is generating out-of-order Packages files (i.e. not using an Ubuntu mirror, and not using Ubuntu/Debian's repo generation tooling either), they could be (unwittingly) relying on this buggy behaviour: fixing it could result in newer package versions ending up in their generated images than currently do, which could have knock-on effects for them somehow. For almost all packages, an `apt-get upgrade` within a system launched from the image would result in the same behaviour, so any such users would have to be not applying upgrades to run into problems.
[Original Bug Report]
Some implementations of apt mirror metadata generation generate Packages files which are not alpha-sorted by package name. apt and britney2 handle these files without issue, but debootstrap does not: it will only consider the first contiguous run of stanzas for a package (taking the last stanza as the latest).
When running debootstrap against a mirror with such Packages files, debootstrap can fail to resolve versioned dependencies which _are_ present in the Packages file, if the satisfying package version isn't within the first contiguous run of stanzas for that package. This leads to avoidable bootstrap failures. (The specific case we hit: each e2fsprogs package Pre-Depends on the libext2fs2 package with the same version: `dpkg --predep-package` finds the newer e2fsprogs version and reports that libext2fs2 needs installing, but debootstrap has already installed (the old) libext2fs2 so errors out.)
The problem lies in the pkgdetails_field function (which is implemented in Perl): https://git.launchpad.net/ubuntu/+source/debootstrap/tree/functions#n1439. It takes a list of expected packages and, once it has found a version for all of them, exits (even if there is more of the Packages file to process). It does already have special-casing for multiple versions of the same package, but only if they are a contiguous run. (That behaviour was introduced by cjwatson in 1.0.38[0] to fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649319: that bug report also has useful background info on why multiple versions of a package in metadata should be supported).
[0] https://salsa.debian.org/installer-team/debootstrap/-/commit/0fbf86aa8fbcd06cb62fddddcfd4605fef2ee8b2
I've created a reproducer (attached, also at https:/
FLASK_APP=repro.py flask run
Once it's running, the reported debootstrap error can be reproduced by attempting to bootstrap from this "mirror" (without GPG verification: that obviously won't work!):
debootstrap --keep-
You should see this fail with:
W: Failure trying to run: chroot "/root/bootstrap" dpkg --force-overwrite --force-confold --skip-same-version --install
This command should have a package name appended to it. debootstrap has installed the older version of libext2fs2 into the chroot (because it failed to find the newer one), but it has written `/var/lib/
Fixing the determination logic in pkgdetails_field so that debootstrap installs the most recent packages initially fixes this problem: the Pre-Depends on the newer package is satisfied, so `dpkg --predep-package` doesn't return it.