[elrepo] kernel/kernel-lts separation

[Manuel Wolfshant]

On 10/12/2012 01:44 AM, Dag Wieers wrote:
>
> Ok, this boils down to having potentially 3 kernels installed 
> 'kernel', 'kernel-lt' and 'kernel-ml'.
You are perfectly correct here, potentially, yes, all three variants 
could be installed in the same time. But OTOH the kernel-lt is intended 
for people who do not want the latest major version so probably they 
would not install kernel-ml in the same time. I assume ( but of course, 
I might be wrong) that people would chose between these two lines of 
kernels depending on their intent.
However I really do not see the problem here. Yes, if one decides to 
install more than one kernel variant, one has to take care of all. Just 
like it would do with a single one. By definition all the kernels coming 
from elrepo come with a disclaimer. Which will affect all kernels that 
do not come from main+updates. no matter if there is one or there are 
more variants.


> If you switch from one to the other you have to manage those sets of 
> packages. For 'kernel' I don't care, that's upstreamn, but what's the 
> added benefit of having kernel-lt and kernel-ml ?

The difference between -lt and -ml boils down to the difference that 
kernel.org makes between stable and long-term. And making sure that 
during an update ( a simple yum update, not necessarily a yum update 
kernel-ml ) the higher versioned kernel-ml packages would not 
inadvertently remove the lower-versioned-but-fancied-by-the-admin 
version. The name change is just a way of helping users to use the 3.0 
line without forcing them to use specific includes/excludes in the repo 
definition files.



>>> >  Besides, we do not influence when a release becomes stable, and 
>>> when it >  not
>>> >  longer is updated. So keeping all under the generic 'mainline' 
>>> brand is >  much
>>> >  clearer.
>>
>> I beg to differ. When time comes we can simply switch to 
>> kernel-lt-4.0.1 instead of 3.0.x. Keeping ALL kernels below the 
>> kernel-ml generic name is exactly the thing which would confuse 
>> potential users looking for the 'long term stable' version ( whatever 
>> version the upstream kernel.org people decide it to be )
>
> The paragraph before we assumed people knew what they were doing, and 
> now we don't ?
>
> But that's not how it works. Stable kernels come and go, you have a 
> few of those stable kernels in parallel. That's what the upstream 
> kernel.org people have decided. Currently the following stable trees 
> exist:
>
>  - 3.0 (at 3.0.45)
>  - 3.2 (at 3.2.31)
>  - 3.4 (at 3.4.13)
>  - 3.5 (at 3.5.6) -> ending
>  - 3.6 (at 3.6.1)
You forgot 2.6.32 and 2.6.34 :) ..... Actually there are no less than 8 
trees marked as "stable" at www.kernel.org
We are not discussing stability here ( we all presume hope that the 
kernels that we get are stable, don't we? [*] ) but long-term maintenance.




> Stable release suddenly stop. Alan decides what versions ELRepo 
> provides, but 'kernel-lt' is a bit shortsighted IMHO.
>
> Besides, what is confusing are 2-letter acronyms. Tell me, what is 
> more confusing, one 2-letter acronym, or two, or four ?
Fine. Then let's call it kernel-mainline-supported-until-2014 instead of 
kernel-lt :)
Seriously speaking now, that's why we are discussing. kernel-lts was 
suggested as a name exactly because LTS already has a known connotation. 
Your idea of creating sub-repositories is a possible alternative. I do 
not like it ( just like I hated the two sets of php packages from 
dev.centos.org ... nobody knew how to get them ) but that's just me. 
Let's hear other opinions as well.


     manuel


* about stability: https://bugzilla.redhat.com/show_bug.cgi?id=863422
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.elrepo.org/pipermail/elrepo/attachments/20121012/7616c869/attachment-0001.html>