[elrepo] RE driver update incompatibility issue

Nicolas Thierry-Mieg Nicolas.Thierry-Mieg at imag.fr
Wed Jan 30 07:42:51 EST 2013


Phil Perry wrote:
> On 29/01/13 19:54, Nicolas Thierry-Mieg wrote:
>> Le 28/01/2013 23:52, Nux! a écrit :
>>> On 28.01.2013 21:26, Lamar Owen wrote:
>>>> The pipe-dream, and a 'better than Windows' experience, is a single
>>>> package set that covers all legacy versions plus the current version
>>>> and leverages udev to load the right bits at boot time. I have no
>>>> clue how difficult that would be to implement, other than it's likely
>>>> to be pretty hard.
>>>>
>>>> As I say, I'm not complaining about the status quo; I'm very grateful
>>>> for all the work that you do and have done in just getting us the bits
>>>> packaged, and packaged very well indeed, IMO.
>>>
>>> Lamar's idea is quite neat! +1
>>
>> indeed that's a very cool idea.
>>
>
> I'll reply to this email first as it's quicker to do than replying to
> Lamar's post (but I'll get to that!)
>
>> one downside though, it means release a new version of the unified
>> nvidia package every time any one of the driver versions gets an update.
>> So whatever version you actually use, if you stay up to date you'll
>> download and install the new package every time.
>> And that will be a massive download... not a problem if you have a fast
>> network, but for some users this may be painful. Maybe also for the
>> elrepo infrastructure (don't know how developed the mirror system is).
>>
>> Not saying it's a show stopper but it might be worth considering.
>
> I don't actually think it would be too bad. Updates to legacy versions
> are not that frequent, and often the changelogs indicate the updates
> aren't relevant to RHEL users anyway. For example, nvidia may backport
> support for a newer version of Xorg into an old legacy driver, which may
> be useful for Fedora users but is often irrelevant for us if our version
> of Xorg is fixed or lagging behind. Thus there's often no need for us to
> roll out legacy updates.

ok, so most of the package updates will happen when the "current" driver 
gets updated.
This mitigates the (slight) issue, but only for people with modern 
hardware (who use and want the updated "current" driver anyway). Users 
who are on a legacy version will still uselessly download a new package 
each time current gets updated.

Nux mentioned deltarpm, fine for rhel6 but not for rhel5 afaik?

Don't get me wrong, I think this is an enticing idea, and there's no 
issue for me since most of my machines are on fast networks. I'm just 
trying to think this through and imagine the potential drawbacks before 
you commit your precious time and energy to it  :-)


>>
>> Another thing: if all kmods are installed, can you make the kernel load
>> the correct one?
>
> My initial thought would be to install all 4 modules in the form of
> nvidia-current.ko, nvidia-304.ko etc, and then to use a script to detect
> the current hardware, select the correct driver and copy that driver
> into place, and finally running depmod. The script could be run during
> package installation and then dropped in place (something like
> /usr/bin/nvidia-select.sh) so the user could manually run it at any time
> should they update their hardware etc.
>
> So to answer your question in the way it is worded, the kernel will
> always load the correct one as that will be the only one available - the
> trick is to ensure it is indeed the 'correct' one that is available.

sounds great!




More information about the elrepo mailing list