Activity log for bug #1979244

Date Who What changed Old value New value Message
2022-06-20 20:53:47 Felipe Reyes bug added bug
2022-06-20 20:55:00 Felipe Reyes nominated for series Ubuntu Jammy
2022-06-20 20:55:00 Felipe Reyes bug task added mysql-8.0 (Ubuntu Jammy)
2022-06-20 20:55:26 Felipe Reyes bug task added charm-mysql-innodb-cluster
2022-06-21 06:27:16 Launchpad Janitor mysql-8.0 (Ubuntu): status New Confirmed
2022-06-21 06:27:16 Launchpad Janitor mysql-8.0 (Ubuntu Jammy): status New Confirmed
2022-06-21 11:40:17 Jeremy Chadwick bug added subscriber Simon Chopin
2022-06-21 11:43:35 Jeremy Chadwick bug task added openssl (Ubuntu)
2022-06-21 11:44:59 Jeremy Chadwick openssl (Ubuntu Jammy): status New Confirmed
2022-06-21 11:45:06 Jeremy Chadwick openssl (Ubuntu): status New Confirmed
2022-06-21 12:03:11 Marc Deslauriers bug added subscriber Marc Deslauriers
2022-06-21 12:14:44 Marcus Dansarie bug added subscriber Marcus Dansarie
2022-06-21 13:50:02 Simon Chopin tags fr-2488
2022-06-22 12:58:18 Felipe Reyes charm-mysql-innodb-cluster: status New Invalid
2022-06-23 09:57:19 Julian Andres Klode bug task added apt (Ubuntu)
2022-06-23 09:57:28 Julian Andres Klode mysql-8.0 (Ubuntu): status Confirmed Invalid
2022-06-23 09:57:31 Julian Andres Klode bug task deleted mysql-8.0 (Ubuntu Jammy)
2022-06-23 09:57:34 Julian Andres Klode bug task deleted openssl (Ubuntu Jammy)
2022-06-23 09:57:39 Julian Andres Klode openssl (Ubuntu): status Confirmed Invalid
2022-06-23 09:58:00 Julian Andres Klode bug task deleted mysql-8.0 (Ubuntu)
2022-06-23 09:58:04 Julian Andres Klode bug task deleted openssl (Ubuntu)
2022-06-23 10:09:40 Julian Andres Klode description 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. [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] As a workaround for this bug, we will limit phasing to when you use the upgrade/dist-upgrade commands. This will mean that the install command below would pick libssl-dev=3.0.2-0ubuntu1.4 and upgrade libssl3 to the same version, despite this not having phased for us yet. This means that trying to do apt dist-upgrade libssl-dev and similar (trying to upgrade and install at the same time) would still not work, but that is a minor concern compared to the current issue. Once launchpad bug 1929082 is resolved, that change will be reverted, and the algorithm for apt changed such that whenever the installed version is larger than the latest "for us" available version (as in, the only newer versions available are still phasing), it will ignore the phasing. This will be dealt with in a separate bug report. [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. [Regression potential] Systems may end up with more packages installed that have not phased enough for them yet, getting somewhat closer to the pre-impish state where apt did not respect phasing at all. Specifically, apt install libssl3 below would upgrade libssl3 to the version we are not yet eligible for. [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.
2022-06-23 10:11:24 Julian Andres Klode 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] As a workaround for this bug, we will limit phasing to when you use the upgrade/dist-upgrade commands. This will mean that the install command below would pick libssl-dev=3.0.2-0ubuntu1.4 and upgrade libssl3 to the same version, despite this not having phased for us yet. This means that trying to do apt dist-upgrade libssl-dev and similar (trying to upgrade and install at the same time) would still not work, but that is a minor concern compared to the current issue. Once launchpad bug 1929082 is resolved, that change will be reverted, and the algorithm for apt changed such that whenever the installed version is larger than the latest "for us" available version (as in, the only newer versions available are still phasing), it will ignore the phasing. This will be dealt with in a separate bug report. [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. [Regression potential] Systems may end up with more packages installed that have not phased enough for them yet, getting somewhat closer to the pre-impish state where apt did not respect phasing at all. Specifically, apt install libssl3 below would upgrade libssl3 to the version we are not yet eligible for. [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. [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] As a workaround for this bug, we will limit phasing to when you use the upgrade/dist-upgrade commands. This will mean that the install command below would pick libssl-dev=3.0.2-0ubuntu1.4 and upgrade libssl3 to the same version, despite this not having phased for us yet. This means that trying to do apt dist-upgrade libssl-dev and similar (trying to upgrade and install at the same time) would still not work, but that is a minor concern compared to the current issue. Once launchpad bug 1929082 is resolved, that change will be reverted, and the algorithm for apt changed such that whenever the installed version is larger than the latest "for us" available version for any binary in the source package (as in, the only newer versions available are still phasing), it will ignore the phasing. This will be dealt with in a separate bug report. [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. [Regression potential] Systems may end up with more packages installed that have not phased enough for them yet, getting somewhat closer to the pre-impish state where apt did not respect phasing at all. Specifically, apt install libssl3 below would upgrade libssl3 to the version we are not yet eligible for. [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.
2022-06-23 10:17:36 Nobuto Murata bug added subscriber Nobuto Murata
2022-06-28 09:34:27 Launchpad Janitor apt (Ubuntu): status New Confirmed
2022-06-28 09:34:27 Launchpad Janitor apt (Ubuntu Jammy): status New Confirmed
2022-06-30 13:49:31 Julian Andres Klode apt (Ubuntu): status Confirmed Fix Committed
2022-06-30 13:49:33 Julian Andres Klode apt (Ubuntu Jammy): status Confirmed In Progress
2022-06-30 13:55:47 Julian Andres Klode 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] As a workaround for this bug, we will limit phasing to when you use the upgrade/dist-upgrade commands. This will mean that the install command below would pick libssl-dev=3.0.2-0ubuntu1.4 and upgrade libssl3 to the same version, despite this not having phased for us yet. This means that trying to do apt dist-upgrade libssl-dev and similar (trying to upgrade and install at the same time) would still not work, but that is a minor concern compared to the current issue. Once launchpad bug 1929082 is resolved, that change will be reverted, and the algorithm for apt changed such that whenever the installed version is larger than the latest "for us" available version for any binary in the source package (as in, the only newer versions available are still phasing), it will ignore the phasing. This will be dealt with in a separate bug report. [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. [Regression potential] Systems may end up with more packages installed that have not phased enough for them yet, getting somewhat closer to the pre-impish state where apt did not respect phasing at all. Specifically, apt install libssl3 below would upgrade libssl3 to the version we are not yet eligible for. [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. [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. [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. 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.
2022-06-30 13:57:23 Julian Andres Klode 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. [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. 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. [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`. [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. 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.
2022-06-30 13:59:37 Julian Andres Klode 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`. [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. 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. [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.
2022-07-01 18:34:37 Launchpad Janitor apt (Ubuntu): status Fix Committed Fix Released
2022-07-02 00:14:32 Steve Langasek apt (Ubuntu Jammy): status In Progress Incomplete
2022-07-02 06:33:29 Julian Andres Klode apt (Ubuntu Jammy): status Incomplete Triaged
2022-07-02 06:33:32 Julian Andres Klode apt (Ubuntu Jammy): status Triaged In Progress
2022-07-04 10:18:53 Łukasz Zemczak apt (Ubuntu Jammy): status In Progress Fix Committed
2022-07-04 10:18:54 Łukasz Zemczak bug added subscriber Ubuntu Stable Release Updates Team
2022-07-04 10:18:55 Łukasz Zemczak bug added subscriber SRU Verification
2022-07-04 10:18:59 Łukasz Zemczak tags fr-2488 fr-2488 verification-needed verification-needed-jammy
2022-07-04 10:28:43 Łukasz Zemczak apt (Ubuntu Impish): status New Fix Committed
2022-07-04 10:28:48 Łukasz Zemczak tags fr-2488 verification-needed verification-needed-jammy fr-2488 verification-needed verification-needed-impish verification-needed-jammy
2022-07-04 15:44:22 Jeremy Bícha apt (Ubuntu): importance Undecided High
2022-07-04 15:44:25 Jeremy Bícha apt (Ubuntu Impish): importance Undecided High
2022-07-04 15:44:29 Jeremy Bícha apt (Ubuntu Jammy): importance Undecided High
2022-07-05 09:50:55 Julian Andres Klode tags fr-2488 verification-needed verification-needed-impish verification-needed-jammy fr-2488 verification-done verification-done-impish verification-done-jammy
2022-07-18 22:57:41 Brian Murray apt (Ubuntu Impish): status Fix Committed Won't Fix
2022-07-28 08:54:50 Launchpad Janitor apt (Ubuntu Jammy): status Fix Committed Fix Released
2022-07-28 08:55:00 Łukasz Zemczak removed subscriber Ubuntu Stable Release Updates Team
2022-10-08 16:45:00 Faisol Lutfi apt (Ubuntu): assignee Faisol Lutfi (lutfi87)
2022-10-08 16:52:14 Julian Andres Klode apt (Ubuntu): assignee Faisol Lutfi (lutfi87)
2022-10-09 00:50:23 Faisol Lutfi bug added subscriber Faisol Lutfi