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.
_______________________________________________
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
