Bug#889669: nvidia-graphics-drivers: solve the upgrade problem

[Philipp Kern]

Hi Luca,

On 3/21/18 2:01 PM, Luca Boccassi wrote:
> Isn't this sort-of-like what Ubuntu does? IIRC they lump together
> everything into a single package unlike we do, and they are named after
> the major revision.

let's say that even Ubuntu have not solved this problem because they
don't consider the minor revision either, as suggested here.

I would like to understand better what the current set of packages helps
with, though. It is true that I hadn't considered that you are shipping
so many packages right now. However, you seem to also hardcode the
dependencies between them with a lot of substvars in the packaging,
which is understandable given the non-free nature of them. But at the
same time it makes it more muddy as to what problem that solves.

At the same time I also did not consider libglvnd - I unfortunately was
not aware of it. That at least in theory seems to be a nice way forward
to just co-install multiple implementations. Is anyone other than NVidia
supporting it at this point? But anyhow we'll live with the two options
here if one of them is a regression, either in bugs or features, which
seems to be the case here. Given that the two are not co-installable
today anyway, collating the two options into two separate packages would
work. But for that suggestion to make any sense I'd like to understand
the current packaging first - as per the above.

The key idea is that the packages install their binaries into paths
versioned with both major and minor revision and do not change while the
machine is booted. Then we would need to juggle around some symlinks
based off the module version exposed in sysfs on boot. The constraints
here are doing that after the module is loaded and /usr is made
available and before X(/Wayland?) starts. It does seem a little messy
with systemd, that's true. We'd likely end up needing this to be
included in basic.target. With sysvinit rcS would work. If the nvidia
module is included in the initrd for KMS - which I think is the case? -
udev wouldn't work as easily, just in addition. So I suppose it'd need
one script that puts the symlink farm into the right state and then we
need to sprinkle some hooks into the right places depending on when the
module is loaded.

What kind of alternatives do we need to offer at this point? Mesa and
NVidia? Can legacy drivers be co-installable? I'd intuitively prefer to
have glvnd/non-glvnd be two non-co-installable packages. It'd be great
if legacy drivers could be co-installable and then the right driver
would be loaded, which is theoretically feasible. And Mesa needs to be
co-installable. So it'd be nice if this would really boil down to just
Mesa vs. NVidia on an alternatives level, unless I miss something.

Kind regards and thanks for all your replies so far!
Philipp Kern