Does not consider all versions in Packages files
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
debootstrap (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
Focal |
Fix Committed
|
Undecided
|
Dan Watkins | ||
Jammy |
Fix Released
|
Undecided
|
Dan Watkins |
Bug Description
[Impact]
Users who build their own Ubuntu images using debootstrap against Debian metadata that is not generated with alpha-sorted-
[Test Plan]
This bug can be reproduced/
[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:/
tags: | added: rls-kk-incoming |
tags: | removed: rls-kk-incoming |
Changed in debootstrap (Ubuntu): | |
importance: | Undecided → Low |
tags: | added: foundations-triage-discuss |
description: | updated |
Changed in debootstrap (Ubuntu Focal): | |
assignee: | nobody → Dan Watkins (oddbloke) |
Changed in debootstrap (Ubuntu Jammy): | |
assignee: | nobody → Dan Watkins (oddbloke) |
Changed in debootstrap (Ubuntu Focal): | |
status: | New → In Progress |
Changed in debootstrap (Ubuntu Jammy): | |
status: | New → In Progress |
I've created a reproducer (attached, also at https:/ /pastebin. ubuntu. com/p/H6dTzGBTG p/). This is a small Flask app which wraps archive.ubuntu.com, and modifies the focal main Packages file to include the e2fsprogs and libext2fs2 packages currently in focal-updates (as well as rewriting other metadata as required). It can be run like this (assuming it's written to repro.py):
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- debootstrap- dir --variant minbase --no-check-gpg focal bootstrap http:// 127.0.0. 1:5000/ ubuntu/
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/ dpkg/available` such that `dpkg --predep-package` does detect the newer version and returns "libext2fs2" as a package that needs installing to satisfy Pre-Depends. debootstrap filters out any already-installed packages from that list, and that's why we don't have any package name appended here.
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.