[elrepo] kernel/kernel-lts separation

[Phil Perry]

On 12/10/12 17:44, Dag Wieers wrote:
> On Fri, 12 Oct 2012, Akemi Yagi wrote:
>
>> Having understood the subdirectory method, I now say I'd prefer the
>> kernel-ml / kernel-lt option for 2 reasons.
>>
>> One is that, as Phil said, having to update the elrepo-release package
>> because of kernel addition does not sound right. We want to keep it as
>> static as we can.
>>
>> Second is from the users point of view. With the split method one
>> would install elrepo kernel by running:
>>
>> yum --enablerepo=elrepo-kernel kernel-ml
>> or
>> yum --enablerepo=elrepo-kernel kernel-lt
>>
>> The choice remains between the two as the kernel version advances,
>> which I think makes it easy for the users.
>
> So, with the risk of beating a dead horse, I discussed the issues that I
> think are valid with Akemi on IRC. In the end it is up to Alan and the
> community to decide what direction to go, but I want to make sure we
> make a decision to change for the right reasons.
>

Alan only really ever wanted to do one kernel - the latest upstream 
kernel. The folks at kernel.org refer to that release as the mainline 
kernel hence Alan called his kernel package kernel-ml.

I later tried to persuade Alan that it might be useful to also keep the 
current "longterm" kernel (again a kernel.org term) as at the time Alan 
was having a few issues transitioning to the latest 3.0 numbering. My 
reasoning was that it was a) a newer kernel than the distro kernel, and 
b) as it had long term support from kernel.org it was something we could 
offer with some consistency during periods when packages for the latest 
mainline kernel were being developed (although these days Alan seems to 
be able to knock out the latest releases with amazing speed).

As there are really only ever two kernels on offer (mainline and 
longterm), to me it makes perfect sense to name them accordingly. What 
"version" or branch they are from is largely irrelevant. Those running 
kernel-ml can expect yum to deliver the very latest kernel to their 
system (be it 3.4, 3.5, 3.6 ...) whereas those running the longterm 
kernel can expect yum to deliver the latest updates to that kernel 
(currently 3.0.y) for as long as kernel.org supports it (currently to a 
minimum of Jan 2014). To me that is the essence of what we (or rather 
Alan) is offering.

My main objection to Dag's proposal is due to the frequency that new 
kernels are released upstream. With new branches released every 6-8 
weeks we'd constantly be creating new directory structures and updating 
elrepo-release to reflect that. If new releases were ~ once per year, 
maybe, but the current upstream release cycle is just way to frequent 
for this method to be efficient IMHO.

I also believe it adds unnecessary complexity - the main problem it 
seems to be trying to solve is allowing a user to stay on an unsupported 
(by kernel.org) release (say 3.5) when the user could just as easily 
achieve this by adding an exclude to prevent the package being updated 
any more once they reach a position where the latest release may no 
longer work for them. This is pretty much standard practice for any 
broken package IMHO and doesn't warrant the creation of separate 
repositories.

The decision to change is driven purely by user requests/expectations 
that yum can/will update within the current 3.0.y "longterm" branch 
rather than update from that to the latest mainline branch as it does 
now. Either of the proposed methods solves the problem at hand, but I 
believe the renaming route offers the best solution for the reasons I've 
outlined.

Phil