[elrepo] RE driver update incompatibility issue

[Phil Perry]

On 04/03/13 17:00, Lamar Owen wrote:
> On 01/25/2013 04:03 PM, Nux! wrote:
>> Hi guys,
>>
>> I just read the SL mailing list thread about the nvidia driver issue;
>> here's an idea:
>> - why not in cases like this send a Requires for some noarch that
>> executes a script and does a "yum replace"[1] based on pci id?
>>
>> How does that sound?
>>
>> [1] -
>> http://dl.iuscommunity.org/pub/ius/stable/Redhat/6/SRPMS/yum-plugin-replace-0.2.5-1.ius.el6.src.rpm
>>
>>
>
> [Following up to an old thread......]
>
> I had opportunity to try out the yum-plugin-replace moving from the
> nvidia-x11-drv package to the nvidia-x11-drv-304xx package on a client's
> CentOS 6 machine, which has a number of packages installed (some of
> which are in repos, some of which are not) that are dependent upon the
> stack based on nvidia-x11-drv and nvidia-x11-drv-32bit, and which would
> be a real hassle to uninstall and reinstall.
>
> However, it didn't go smoothly, requiring a manual nvidia-xconfig run to
> disable nouveau completely.  The replace plugin does an install, then
> erase, much like an update does, but the 'nvidia-ized' xorg.conf wasn't
> set back up.
>

Thanks for that Lamar.

As you are no doubt aware, an "install/uninstall" action is very 
different from an "update" action and the rpm level.

The relevant rpm scripts are in %post and %preun and are conditional.

The %post script is only run for new installs, not updates.

The %preun script is only run for uninstalls, not updates.

So basically we only set stuff up on the first install and only undo our 
changes on the final uninstall. Intermediate package updates do not 
alter the users system.

The %preun of the old package is run *after* the %post script of the new 
package. This, if the plugin is treating this package replacement as an 
install/uninstall process as opposed to an update process then the 
%preun script will undo everything the %post script just did.

Without examining the plugin in more detail I'm just hypothesizing that 
this might be what is happening.

> Running nvidia-xconfig and rebooting fixes the problem.

If it's just a case that the scripts need to be (re)run, perhaps a 
simple 'yum reinstall nvidia-x11-drv' would suffice? (all the scripts 
are in the nvidia-x11-drv package).

>
> Just a heads up for anyone trying the yum-plugin-replace approach; it
> does work to prevent dependency issues (and issuing :
> yum replace nvidia-x11-drv --replace-with nvidia-x11-drv-304xx
> does work, and does properly depsolve, although you have to tell it that
> an error in checking all dependencie is OK (I forget the exact wording),
> and installs the kmod and if needed the -32bit subpackage).  But you
> have a step left to do after it's done, and that's nvidia-xconfig.
>
> Also, Phil, thanks for the nvidia-detect package and tool, as well as
> the list of cards on the legacy drivers' pages.  That's very useful stuff.
>

Thanks for that.

Undoubtedly the best source of information is NVIDIAs own documentation, 
and that is where I pull the device-id's from for nvidia-detect:

ftp://download.nvidia.com/XFree86/Linux-x86_64/310.32/README/supportedchips.html

As an aside, I have recently added Optimus detection to nvidia-detect:

https://github.com/elrepo/packages/commits/master/nvidia-detect

I don't know too much about Optimus setups, so what we choose to do once 
we have detected Optimus is open for discussion.

I took a very simplistic approach to detecting possible Optimus hardware 
configurations and simply concluded that if both NVIDIA and Intel 
display controllers were visible on the PCI bus then it's Optimus. This 
approach made it trivial to probe the PCI bus for the device_class and 
detect Intel display controllers by vendor_id. Please feel free to 
correct me if this view of Optimus is over-simplistic or incorrect, or 
if anyone has a better solution (I really didn't want to get into 
parsing device-id's for Intel devices).

These Optimus updates will be in the next packaged update, but if folks 
want to have a play with this I can push a package update out sooner 
rather than later (I had planned to release nvidia-detect updates in 
line with driver update releases assuming I'd only be adding detection 
for newly supported NVIDIA devices).