[elrepo] RE driver update incompatibility issue

[Phil Perry]

On 30/01/13 12:42, Nicolas Thierry-Mieg wrote:
> 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.
>

Logically it would make more sense for legacy users to stay on the old 
(existing) legacy packages.

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

Indeed. We would be looking for solutions that largely support all 
currently supported versions of RHEL (or at least all those elrepo 
supports).

> 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!
>

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.