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
signature.asc
Description: This is a digitally signed message part
