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
