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
