The verification of the Stable Release Update for dpkg has completed
successfully and the package is now being released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report. In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dpkg in Ubuntu.
https://bugs.launchpad.net/bugs/2128606
Title:
Correctly copy Architecture-Variant field
Status in dpkg package in Ubuntu:
Fix Released
Status in dpkg source package in Questing:
Fix Released
Status in dpkg source package in Resolute:
Fix Released
Bug description:
[Impact]
amd64v3 packages are differentiated from amd64 packages by
Architecture-Variant: amd64v3
When APT sees amd64v3 packages, it considers them an upgrade to amd64
packages, so when amd64v3 is enabled, a dist-upgrade first upgrades
you to amd64v3.
Inadvertently, dpkg did not copy the field when installing the
package, causing apt to consider the installed amd64v3 package as
amd64 again, and the next dist-upgrade trying to "upgrade" them again.
[Test plan]
Check that the field appears in dpkg --status when installing an amd64v3 package
Check that the field disappears in dpkg --status when installing an amd64 package.
If no amd64v3 packages are involved the field always remains NULL (no
Architecture-Variant is written to the status file); so no visible
change is seen on any system in the real world now; as amd64v3 is opt-
in and not yet announced.
Do a release-upgrade in a lxd container with the new dpkg available
and installed during the upgrade; vs a lxd container without the new
dpkg, and ensure there are no regressions.
[Where problems could occur]
The field could be garbage if not initialized (covered by "install an amd64 package"). The default value of the field is NULL; this is not a concern:
The field is used here:
src/deb/build.c
487: pkg->available.arch_variant ? pkg->available.arch_variant : pkg->available.arch->name, DEBEXT);
^ this is unaffected by the change as available always contains the
field if availabe
lib/dpkg/parse.c
66: { FIELD("Architecture-Variant"), f_charfield, w_charfield, PKGIFPOFF(arch_variant) },
- w_charfield will now write that field if set (it checks if the field
value is null and skips it, which always happened so far)
src/main/unpack.c
908: pkg->installed.arch_variant = pkg->available.arch_variant;
^ here we copy the available value to the installed database, this is
the new line. It's a no-op everywhere that doesn't have amd64v3
packages about to be installed (copying default NULL to NULL, nothing
else set the field of course).
lib/dpkg/dpkg-db.h
124: const char *arch_variant;
^ declaration of the field inside the struct
The only thing that reads the field outside of dpkg is apt when it
sees if the installed version is the same as an available version:
There it checks if they have matching variants. A variant is always
preferred over an architecture.
If no variants where ever configured or force-installed, variants do
not appear anywhere on the system.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/2128606/+subscriptions