[elrepo] kernel/kernel-lts separation

[Manuel Wolfshant]

On 10/12/2012 12:44 AM, Alan Bartlett wrote:
> On 11 October 2012 22:23, Dag Wieers<dag at wieers.com>  wrote:
>> On Thu, 11 Oct 2012, Phil Perry wrote:
>>
>>> On 10/10/12 23:30, Trevor Hemsley wrote:
>>>
>>>>   I'd suggest kernel30 rather than kernel-lt since the long term in this
>>>>   case is not that long and soon we'll be trying to work out how to change
>>>>   kernel-lt-3.0-x to kernel-lt-3.8.x or whatever the next LTS kernel
>>>>   happens to be.
>>>>
>>> Unless the desired action is to update to the latest LTS kernel at that
>>> point? At which time a user can add an exclude for kernel-lt if they want to
>>> stay at an unsupported 3.0.y.
>>>
>>> But I take your point. What do others think?
>>
>> I am not in favor of renaming the packages to kernel-lts (or anything but
>> kernel-ml). For all practical purposes, sticking to one name, but offering
>> (sub)repositories for the different versions offers everything.
>>
>> So I would propose this:
>>
>>    kernel-ml/
>>    kernel-ml/repodata/
>>    kernel-ml/3.0/
>>    kernel-ml/3.0/repodata/
>>    kernel-ml/3.8/
>>    kernel-ml/3.8/repodata/
>>
>> You can select the specific version you want to hook into, either the parent
>> directory if you prefer to stick with the latest, or one of the major
>> version repositories.
>>
>> If you have different names for different releases (or even just the ml/lts
>> split) it becomes harder for the user to understand how this affects the
>> system.
That is mostly true. But since these packages are intended for people 
who know what they do, not regular centos/rh users, I do not think that 
this matters. This kind of people should either know how to read or 
stick to doing something else.


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




>> Is there a need for the proposed complexity ?
> Hmm . . . so what has been proposed is complex but what you propose,
> above, is not added complexity?
The basic idea was to make choice easier by using a different name. 
Separating the so called long-term packages in a different [sub]repo 
does not achieve this  goal.
I find the idea of adding subrepos the most inconvenient of all 
approaches suggested so far.