[elrepo] Kernel-ml Packages for EL6

[Phil Perry]

On 05/08/11 18:43, Dag Wieers wrote:
> On Fri, 5 Aug 2011, Alan Bartlett wrote:
>
>> On 4 August 2011 20:59, Alan Bartlett<ajb at elrepo.org>  wrote:
>>
>>> Now another request for your input, please. What should I do with the
>>> kernel-ml-firmware package? If you cannot immediately see the
>>> significance of my question, consider what I had to do with the
>>> kernel-headers for EL5. No doubt our friendly RPM packaging guru, Dag
>>> Wieers, will make a few comments but I would like all of you so
>>> interested to discuss it here, please. If I do not join in the
>>> discussion, or otherwise respond, please be aware that I will still be
>>> following the proceedings with interest. My ultimate choice will be as
>>> a result of your deliberations.
>>
>> My latest status update.
>>
>> All is well in the kernel-ml spec file up to and including the one
>> line following the call of the "clean" macro. What remains to be done?
>> The requisite "post", "preun" and "files" sections.
>>
>> Any views on the kernel-ml-firmware package, as mentioned yesterday?
>> Or do you all intend to give me "free rein" and then criticise what I
>> ultimately provide? :)
>
> I don't think there's much we can do, like kernel-headers. Either update,
> or conflict. But since we don't expect the kernel-ml to be an upgrade
> path, I would make it conflicting (and thus a manual step).
>
> There is a big difference between kernel-headers and kernel-firmware in
> the sense that newer firmware may not work with older kernels, or older
> firmware may fail with newer kernels. But if that's the case it's not
> designed very well (the aim is to be able to have multiple kernels that
> can be booted at all times, right ?)
>

Yes, that is the crux of the matter.

> In any case, users are on their own so I wouldn't make it easy to install
> kernel-ml-firmware (and hard to go back), I prefer to make it hard to
> install (and hard to go back ;-)). What do others think ?
>

I would make installing kernel-ml-firmware optional rather than 
mandatory - IOW, I wouldn't add a Requires to kernel-ml for 
kernel-ml-firmware (the distro kernel Requires kernel-firmware >= 
%{version}-%{release}). If users need the newer firmwares because some 
driver in kernel-ml doesn't work without it then they can install it; at 
that point kernel-ml-firmware has to Obsolete kernel-firmware meaning 
kernel-ml-firmware will "update" kernel-firmware.

So, end user might:

1. Install kernel-ml and test.
2. install kernel-ml-firmware as required which would replace 
kernel-firmware.

If end user wishes to revert back to a distro kernel, simply uninstall 
kernel-ml-firmware and (re)install kernel-firmware.

As Dag highlighted above, the issue will be when users want to boot back 
and forth between distro and kernel-ml kernels and they rely on modules 
with firmwares that are not backward and/or forward compatible. You're 
not going to know how much of an issue this is until end users with 
affected hardware start testing those modules/firmwares.