Hi! > > Thanks for spotting this. This actually means that due to changes in > > how the apt resolver works, upgrades from Bookworm to Forky are broken > > for anyone running MariaDB. > > Julian commented on the resolver bits and the bug in your packages. > Let me correct the (repeated) misconception here: > An upgrade from bookworm -> sid/forky is performed by apt/bookworm, > not by apt/forky, in the general case.
We have extensive CI that tests this upgrade (see previous messages and links to CI) which simulates users who have installed something in Debian Bookworm that depends on default-mysql-server. These CI tests have been passing for years and started failing now due to a new apt/resolver. If this is the result of a new version of apt/bookworm or apt/forky I don't know for sure, I guess that is something to debug as part of this bug report. > More importantly, a call like > "apt install foo" is NOT representative of an upgrade. This is a simplified case to reproduce the issue. The full CI code runs`apt-get full-upgrade` to exactly simulate the case a end-user would have, see CI code at https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/salsa-ci.yml, or read the CI logs linked to earlier, they show each command followed by its output. If may of course be that the CI has been running `apt-get full-upgrade` wrongly for years and years, or that the package depends/breaks relationships have been wrong for years and only now surfaced as the resolver was "fixed" to no longer satisfy "wrong" relationships, but I wouldn't jump to that conclusion just yet. Also, even in the case that the resolver is now "correct", if there are a large number of packages that depend on the old behaviour, the new correct might still not be the optimal solution. Assuming the apt changes were recent, let's see if other package maintainers report similar issues that updates with virtual/indirect packages no longer pull in what they used to.
