apt will not install nvidia-driver-470-server if nvidia-driver-450-server is installed and out of date

[dann frazier]

apt/jammy

apt will refuse to install nvidia-driver-470-server if nvidia-driver-450-server is installed *and* out of date. I can reproduce this by disabling all but the jammy release pocket, installing the old n-d-450-s from there, and then enabling updates and trying to install n-v-470-s (where a new
n-d-450-s is available):

# libnvidia-gl-450-server has an update available
root@dannf-apt-jammy:/var/cache# apt install --dry-run libnvidia-gl-470-server -o Debug::pkgProblemResolver=yes
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:
 libnvidia-common-450-server : Conflicts: libnvidia-common
 libnvidia-common-470-server : Conflicts: libnvidia-common
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

[Lukas Märdian (slyon)]

Does this also happen when you use the more recent version 2.4.8 from the jammy-updates pocket?

[Julian Andres Klode (juliank)]

It does yeah, and obviously that's a solver bug that's going to need some more work to root cause.

[Dimitri John Ledkov (xnox)]

One should use ubuntu-drivers CLI or Additional Drivers GUI to install or switch nvidia graphics stacks from one major series to another. It ensures that correct matching pre-signed kernel drivers are installed together with the right userspace (with and without gui stacks, as needed).

[Julian Andres Klode (juliank)]

Reproduced issue and dumped test case into https://salsa.debian.org/apt-team/apt-tests/-/blob/main/edsp/fail-ubuntu-1992513.edsp.log for future analysis when doing solver work.

[Julian Andres Klode (juliank)]

I think we debugged this recently but I'm not sure where the end result of this is that we do not mark packages for removal that have an upgrade available, hence we end up without a removal request after the first stage solver, and the Conflicts solver that runs after can't solve that.

[Julian Andres Klode (juliank)]

I'm going to set this to Won't Fix because that seems to be an important part of the solver logic, and the workarounds - running upgrade first, or using ubuntu-drivers - are easy to do and the potential for regression significantly outweighs them.

This will get solved eventually by a nicer solver (a proper optimization solver) sure, if we make it there. Lots of caveats because I'm not that clever that I want to write a competitive partial weighted maxsat or linear programming solver, so end up reusing libraries, and neither z3 nor clasp are exactly optimal (also figuring out how to get them to explain uninstallability is hard).

On the other hand, I am also exploring preventing the solver (both old and new) from removing packages due to Conflicts, so removals can only happen as part of a dist-upgrade or an explicit removal request, to further reduce issues with people breaking their systems by accidentally removing half of it (caveats as to the scope with manually vs automatically installed packages, and whether packages are not needed anymore are to be).