[elrepo] kernel/kernel-lts separation

[Dag Wieers]

On Thu, 11 Oct 2012, 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.
>>
>> 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.
>>
>> 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?

I didn't know complexity was a boolean. ;-) The proposal was to add 
repositories and change the package name. I don't see a good reason for 
the second change, in fact I see many reason to not make the second 
change.

-- 
-- dag wieers, dag at wieers.com, http://dag.wieers.com/
-- dagit linux solutions, info at dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]