[elrepo] kernel/kernel-lts separation

[Dag Wieers]

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 ?

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