[Bug 1979244] Autopkgtest regression report (apt/2.4.6)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted apt (2.4.6) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

apport/2.20.11-0ubuntu82.1 (amd64)


Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/jammy/update_excuses.html#apt

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1979244

Title:
  libssl-dev : Depends: libssl3 (= 3.0.2-0ubuntu1.1) but
  3.0.2-0ubuntu1.2 is to be installed

Status in MySQL InnoDB Cluster Charm:
  Invalid
Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Impish:
  Fix Committed
Status in apt source package in Jammy:
  Fix Committed

Bug description:
  [Impact]
  Users cannot install a package, e.g. libssl-dev, if built from the same source as another installed update while it is phasing.

  In the example below, libssl3 3.0.2-0ubuntu1.2 update was already
  installed, this got replaced in the archive with a 3.0.2-0ubuntu1.4
  update that was phasing and the system in question was not eligible
  for it yet.

  Because the system was not eligible for openssl 3.0.2-0ubuntu1.4, it
  picked libssl-dev=3.0.2-0ubuntu1.1 from the security pocket as the
  candidate instead, which conflicts with the higher version of libssl3.

  [Approach]
  We reimplemented the phasing as part of the upgrade code path by keeping back any phased upgrades, as the original update-manager implementation does, and disabled the policy based implementation (set APT::Phase-Policy to true to re-enable it).

  This means that phasing only applies when upgrades are made by apt,
  and not when initiated manually by the user or as a result from a
  dependency.

  So if you have a phased upgrade 'phased', apt upgrade won't upgrade
  it, but `apt upgrade 'phased'`, like àpt install 'phased'` will -
  which is the expected behavior as the arguments should behave like
  they do in `install`.

  Packages will now appear as having "been kept back" in the upgrade
  output.

  [Test case]
  Integration tests will be provided and run as autopkgtests, testing the scenarios described in this issue and comment #10. This cannot necessarily be tested on the real archive as you need packages phasing and have an older version installed.

  Please see test/integration/test-phased-updates-upgrade for the
  complete tests. tl;dr is that we test each of the upgrade commands,
  with and without package arguments, and the install command with
  arguments; for a variety of scenarios:

  – simple phased update
  - a phased update that has a version in security
  - a package that gains a dependency on an installed phased package
  - a package that gains a dependency on a NEW phased package

  We test both the new implementation and the old one.

  [Regression potential]
  The solver could break trying to unwrap our mess of MarkKeep() calls where they conflict with other calls. I don't think it can necessarily break harder than now and issues can be worked around archive side if problems do pop up. Also people can manually work around by passing package names of phased upgrades to force them.

  Packages will now be installed from the -updates pocket if they have a
  newer-than-installed version in the -security pocket, rather than the
  security pocket, as we cannot switch the version. This is the same
  behavior as update-manager.

  [Example]

  libmysqlclient-dev on Jammy cannot be installed due to unmet
  dependencies

  $ apt policy libmysqlclient-dev
  libmysqlclient-dev:
    Installed: (none)
    Candidate: 8.0.29-0ubuntu0.22.04.2
    Version table:
       8.0.29-0ubuntu0.22.04.2 500
          500 http://nova.clouds.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
          500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
       8.0.28-0ubuntu4 500
          500 http://nova.clouds.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
  $ sudo 'apt-get' '--option=Dpkg::Options::=--force-confold' '--assume-yes' 'install' 'libmysqlclient-dev'
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   libssl-dev : Depends: libssl3 (= 3.0.2-0ubuntu1.1) but 3.0.2-0ubuntu1.2 is to be installed
  E: Unable to correct problems, you have held broken packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-mysql-innodb-cluster/+bug/1979244/+subscriptions