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

[Philipp Kern]

On 2018-03-30 20:02, Luca Boccassi wrote:
> On Mon, 2018-03-26 at 18:45 +0200, Philipp Kern wrote:
>> 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.
> Well that's the Debian policy - one shared library per package, that's
> what we follow.

While this is technically true, they are also far from the regular 
shared library packages, too. People generally don't link against these 
shared libraries. Files are installed not into the regular directories. 
Most of the time newer libraries are not actually co-installable. The 
installed file doesn't necessarily follow the SONAME. (I only spot 
checked as I have spotty connectivity right now.)

This is not about "you're doing it wrong or anything". Instead these are 
just awkward binary blobs that I think can be treated differently than 
usual shared libraries if needed. Especially in case you don't get the 
advantages of the split packaging with the binaries you are provided by 
NVidia.

I'll try to come up with a longer answer to the remaining bits. I 
suppose we should play this through as an example with the current 
packaging and then check what's acceptable and what's not acceptable.

> Yes, the legacy drivers (340xx and 304xx at the moment, although the
> latter is out of support so I guess we'll drop it in buster) are co-
> installable. There are update-alternatives for those too. We have a
> script to make it easier to manage those and the glx provider (mesa,
> fglrx, nvidia), it's update-glx from the update-glx package.
> 
> You can find the scripts and configs in the git repo:
> https://salsa.debian.org/nvidia-team/glx-alternatives

This means that users are expected to call update-glx on bootup if the 
driver in the installation doesn't match the installed hardware, right? 
My hope would be that if we get it to work consistently for minor 
revisions that we can support legacy drivers with the same mechanism: 
When a legacy module is loadable, we make sure that the GLX bits point 
to the correct library version for the card installed. I know that in 
regular desktop systems card architecture changes are rare and users 
expect to tend to the machine manually in this case. However in the case 
of bigger pool setups and imaging, modern Linux and X.org just works, 
except the NVidia bits.

Kind regards and thanks a lot for your responses!
Philipp Kern