[Bug 2128606] Re: Correctly copy Architecture-Variant field

[Julian Andres Klode]

** Description changed:

  [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.

-- 
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 Committed
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