Bug#1121158: apt: 3.1.x no longer upgrades MariaDB Recommends on upgrade
On Fri, Nov 21, 2025 at 11:46:43PM +0000, aquilamacedo@riseup.net wrote:
> Package: apt
> X-Debbugs-Cc: aquilamacedo@riseup.net, otto@debian.org
> Version: 3.1.12
> Severity: normal
>
> Hi,
>
> This is a follow-up / underlying issue for Bug#1121151 against
> mariadb-server ("Salsa CI 'default-mysql-server and Bookworm upgrade'
> job fails due to provider plugin ABI mismatch").
>
> While debugging that CI failure, we found that apt's resolver behaviour
> changed between 3.1.8 and 3.1.10/3.1.12 in a way that leaves already
> installed Recommends at old versions in a real upgrade path, which then
> breaks MariaDB.
[...]
> Now, with apt 3.1.12, the same command upgrades mariadb-server to 11.8.3
> but leaves all mariadb-plugin-provider-* at the old 10.11.14 versions
> from bookworm. The system ends up with:
>
> - server: 11.8.3
> - providers: 10.11.14
>
> and MariaDB fails to start with DAEMON plugin API errors, for instance:
>
> ERROR: mariadbd: Can't open shared library 'provider_bzip2.so'
> (errno: 8, API version for DAEMON plugin provider_bzip2 not supported
> by this version of the server)
This is a bug in the packaging which does not express those dependencies
either as versioned dependencies or breaks in either direction (which
one to pick is tricky, plugins breaking the server is _technically_
wrong as the server upgrade is breaking it, but it probably has fewer
chances of removing the server as the server breaking a plugin).
>
> This regression is visible in CI:
>
> - Old passing job (before apt change): upgrades providers too:
> https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/8421127
>
> - New failing job with apt 3.1.12: only the server is upgraded:
> https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/8590614
>
> Summary of regression:
>
> Previously (3.1.8), "apt-get install default-mysql-server" would also
> upgrade the already-installed mariadb-plugin-provider-* Recommends when
> newer versions were available, so server and plugins stayed in sync.
Not really. What you'll find is that the old solver has a special case
to *try* to upgrade all binary packages in a source packages together.
This has been infeasible in the new solver until last month, but may
be feasible now that we have eager Recommends. It may ultimately fail
validation against Canonical's internal solver regression test suite
(which is internal because it runs on private data reported by real
world users).
At no point did we guarantee upgrading all packages, but it is useful to
paper over bugs like this so they hit fewer users.
On the flip side even with the old solver (and once this is reinstated),
CI likely should set APT::Get::Upgrade-By-Source-Package to false to
ensure that the packaging is actually correct.
> Now (3.1.10-3.1.12), the solver considers those Recommends already
> satisfied and leaves them at the old version, which in this real upgrade
> path produces a broken MariaDB installation.
>
> This seems related to enabling the new solver3 by default in 3.1.10 and
> its handling of already satisfied Recommends, but the practical issue is
> that a stable apt update changed resolver behaviour and broke a real
> bookworm -> sid upgrade scenario that used to work.
This is a misconception, APT uses the odd/even version scheme,
3.1.10 is the 11th development release of the 3.2 series (and
3.9.0 is the first development release of the 4.0 series).
While we hold each (pre-)release to the same requirements in terms
of functional stability, odd releases are allowed to make breaking
changes relative to a previous release.
That is, changes are released to development series when they are
ready, and not queued up in say experimental for a big eventual drop.
The exception are the .9 series every 5 years which break the API
and ABI; A.9.C lands in experimental first until the A{P,B}I are
finalized.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: