[elrepo] RE driver update incompatibility issue

[Phil Perry]

On 02/02/13 14:06, Lamar Owen wrote:
> On 01/30/2013 08:12 AM, Phil Perry wrote:
>>
>> I may have jumped the gun here somewhat. Managing the kernel module is
>> probably the easy part. I forgot about the hard part, and that is
>> managing the many linked X11 libraries that are also version-specific.
>
> Ok, another track here.
>
> Phil, how difficult do you think it would be to have all the packages be
> installable both individually and side-by-side? That is, have multiple
> versions of the kmod and the X bits installed, into different
> nonconflicting directors? Then, use alternatives to manage the different
> trains? That way, I could install the legacy train with the mainline
> installed, switch to it with alternatives, and uninstall the mainline,
> which wouldn't break dependencies. And, when/if I upgrade my video card
> I can install the mainline, switch to it, and uninstall the legacy,
> again without breaking deps or configs. I have no idea how difficult
> that would be, either.
>

I guess that sounds doable in principle.

Without knowing how alternatives works, I guess installing each package 
in it's own space, and then have some script copy all the files to their 
correct location based on which driver is selected, create the symlinks 
etc and do any other housekeeping tasks is what would be required. If 
one can do those things from within a RPM package then I see no reason 
why a script couldn't handle it too. You would have to call weak-modules 
to handle the kABI tracking kernel module.

TBH, any such solution is (a) going to require a major non-trivial 
rewrite and (b) significantly diverges from the packaging paradigm. For 
these reasons I'm extremely reluctant to pursue such a solution if for 
no other reason that adding such complexity is almost certainly going to 
add an increased risk of unreliability.

> Then, an early warning 'system' of sorts with the next to last and last
> packages in the mainline (if possible) before another legacy train is
> forked from the mainline could give some sort of notice to the user; how
> this notice is given I don't know. But if there were some way to
> gracefully regress to the vesa framebuffer or even noveau if the
> mainline driver can't load.....
>

Yes, that would be nice. Unfortunately it's not easy, and even more 
difficult on el6 where we need to specifically blacklist the nouveau 
driver to prevent it from loading - it makes it hard to undo our changes 
and gracefully fall back without a complete package uninstall.

> Or maybe a check in %pre that can abort installation of the driver if
> the hardware isn't supported, leaving the old one in place?
>

Can this be done? Can one abort a package installation from a %pre script?

Even if it is possible, how would one handle deps in a yum transaction? 
nvidia-x11-drv requires kmod-nvidia of the same version and vice versa. 
If you abort the installation of one, that will affect other packages in 
the yum transaction and the depsolve resolution is already done at this 
point and the transaction underway.

The more I look at this whole issue the more I see there are no easy 
solutions.

Moving forward, I have been writing a utility (nvidia-detect) to detect 
NVIDIA graphics cards and recommend the appropriate driver. Here is some 
example output:

$ nvidia-detect
Probing for supported NVIDIA devices...
Found: [10de:0ca3] NVIDIA Corporation GT215 [GeForce GT 240]
This device requires the current NVIDIA driver (kmod-nvidia).

$ nvidia-detect
Probing for supported NVIDIA devices...
Found: [10de:0392] NVIDIA Corporation G73 [GeForce 7600 GS]
This device requires the NVIDIA legacy 304.xx driver (kmod-nvidia-304xx).

The program may also be run from a script and will return values based 
upon the appropriate driver. Return codes are:

0: No supported devices found
1: Device supported by the current NVIDIA release driver
2: Device supported by the NVIDIA legacy 96.xx driver
3: Device supported by the NVIDIA legacy 173.xx driver
4: Device supported by the NVIDIA legacy 304.xx driver

Being able to run from a script might prove useful in automating the 
process of detecting if the current driver supports the installed device.

As a standalone utility it should be useful in (a) allowing users to 
select the correct driver for their device, and (b) could be useful in 
determining if a new driver supports their device before updating. 
Taking the recent case as an example, if a user has v304 of the driver 
installed and yum tells them there is a new version (310.xx) available, 
they could:

yum update nvidia-detect

which would pull in the new version 310.xx of nvidia-detect. Running 
that new version would confirm to the user that their graphics card is 
either still supported by the current driver at which point it is safe 
to 'yum update kmod-nvidia' or it is now only supported by the legacy 
304.xx driver at which point they should not update. Maybe we can come 
up with a way to automate that process, but at least we will now have a 
tool to help in that.

I'm just in the process of packaging the program and hope to release it 
to elrepo soon. I'd appreciate testers and feedback.