Am Sat, Nov 22, 2025 at 12:05:25PM -0800, schrieb Otto Kekäläinen: > > 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.
So, have you read what you want others to look at or … ? If you had, you would have noticed that the CI test that failed uses 'apt install', also apparent by the "fix"¹ that was deployed for that test to make it green, because green is good. See e.g. https://salsa.debian.org/mariadb-team/mariadb-server/-/jobs/8622649#L1881 Never mind that many of the tests are testing entirely unsupported setups – as skipping releases is not supported in Debian. But as long as they are green, never mind what they actually test, I suppose. ¹ I at least would not expect users to write this monstrosity of an install command, but if you are set on not fixing your dependencies as suggested by Julian… oh well. > 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. As mentioned, the old resolver implemented that behaviour since *drumroll please* bookworm. So your test worked "for years and years" just because it was added right after apts default resolver tried to help users by papering over insufficient dependencies. This behaviour can be disabled in the old resolver (some users do) and the old is far from the only solver used in the wild, e.g. aspcud for experimental builds and by adventures users, aptitude, … which all do not have this behaviour (as it has the obvious downside of pulling too much into the upgrade set if the maintainer wrote sufficient deps). > 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. Julian already said that he wants to add this user-protection feature to the new resolver as well. But even if he does, any number of packages that rely on it remain RC-buggy for declaring insufficient dependencies and users that not use apt (and its default config) will continue to run into problems with these packages. > 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. APT behaviour is not a popularity contest. Never mind that by the time this popularity contest would find traction is as explained earlier in the forky to duke upgrade – so way too late if you don't want to displease the stable release managers of forky and the release team trying to release duke at that time around duke hard freeze. Your problem is also not about "virtual packages" (see Debian policy what that is) nor "indirect packages" (whatever that may be). Your packages do not pull in what they need, period. That didn't change. What changed is that apt was graciously papering over your bug by assuming you meant to pull those into the upgrade set, too. It currently doesn't anymore, maybe it does again by the time forky is released. Until then users of non-defaults might even consider that an apt feature as it directly helps them by having users with the defaults run into the same problem they encounter. As Julian already said, it might make sense to disable this behaviour in tests if it is reintroduced. Best regards David Kalnischkies
signature.asc
Description: PGP signature
