Bug#590221: Bug #590221 Package: nvidia-glx-legacy-173xx

[Russ Allbery]

Steven Altermatt <stevealcnm at gmail.com> writes:

> Russ Allbery writes:
> "Installing the source package pulls in nvidia-glx via Recommends.
> nvidia-glx in turn requires a kernel module, so apt-get and aptitude look
> for some way to get a kernel module, find DKMS, and install the -dkms
> package and its requirements, which include such things as kernel headers
> and a compiler matching the compiler used for your kernel."

> I guess my final question is how can the -source pkg be installed w/o the
> above happening, like it was before for users like me.

You presumably had built and installed the module packages corresponding
to the version of nvidia-glx that you had installed, so everything was
happy and all dependencies were satisfied.  But when you went to do an
upgrade, then apt tried to install the new nvidia-glx, which previously
would have blocked on you installing the newer module, and found the DKMS
solution.

> It would appear to me your suggestion -

>  "I think the solution for your particular problem would be to downgrade the
> Recommends of nvidia-glx from nvidia-kernel-source to a Suggests."

> would be the way to go.

We've just now uploaded a new version of the package that implements that
change.

Note, though, that if you try to upgrade nvidia-glx before you build a new
module with nvidia-kernel-source, it will still try to install DKMS.  So
it may not make what you observed entirely go away.  What it will allow
you to do is back out of that and then explicitly upgrade just
nvidia-kernel-source to the new version.  Even with Recommends turned on,
that will no longer still try to pull in DKMS.  But the default upgrade of
nvidia-glx still will.

> The only problem I experienced before was forgetting to install glx
> after installing the new kernel module. Just had to install it before I
> could get into X. It would seem if the module build process included
> post-install hooks or something similar to pull in the correct glx pkg
> upon it's install that would help.

It's in general not really safe to try to install packages in an automated
way like that.  Too many weird things can go wrong.

> I suppose I could look into using the dkms, but I like to do it the old
> way myself. I did try it once a few years ago, but it didn't seem
> ready. I always built custom kernels for performance and the ability to
> only load needed modules or build in what's needed. Back when I started
> that it seemed to add to security - maybe an illusion now.

It probably still does add security if you have untrusted local users or
the possibility of running untrusted local code, since you miss all the
privilege escalation vulnerabilities in drivers you didn't build.

> OK, one more question. If I had built and installed the custom headers,
> would dkms find that and not want to install other kernel stuff, or are
> the meta pkgs what it looks for?

I'm not entirely sure.  I think it should work if you have a
/lib/modules/<version>/build directory or link that contains the kernel
headers and build system, but I haven't looked at the details of exactly
how DKMS works and how it finds the pieces of the kernel it needs.

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>