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

[Luca Boccassi]

On Mon, 2018-03-26 at 18:45 +0200, Philipp Kern wrote:
> 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.

Well that's the Debian policy - one shared library per package, that's
what we follow.

> 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.

Mesa does support glvnd, and ships with it in sid/buster. One day I'd
like to drop the non-glvnd one, but it would need a solution for
switchable graphics first (hopefully server-side glvnd in Xorg 1.20
will help with that, but can't say I have looked into it yet).

> 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.

The modules are not in the initrd (weirdly, I thought they would), at
least on my desktop:

$ lsinitramfs /boot/initrd.img-4.9.0-6-amd64  | grep nvidia
lib/modules/4.9.0-6-amd64/kernel/drivers/net/ethernet/nvidia
lib/modules/4.9.0-6-amd64/kernel/drivers/net/ethernet/nvidia/forcedeth.ko
etc/modprobe.d/nvidia-kernel-common.conf
etc/modprobe.d/nvidia.conf
etc/modprobe.d/nvidia-blacklists-nouveau.conf
etc/nvidia
etc/nvidia/current
etc/nvidia/current/nvidia-modprobe.conf
etc/nvidia/current/nvidia-blacklists-nouveau.conf

> 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

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

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20180330/473d32d8/attachment.sig>