[elrepo] kernel/kernel-lts separation
Alan Bartlett
ajb at elrepo.org
Thu Oct 11 17:44:06 EDT 2012
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?
Perhaps the simplest thing is for me is to type: "No. No change. No
nothing. No further releases from me. I've shown you all how to do it,
now get on with it yourselves." :-)
But I won't. I will hand the decision process over to my number two,
Akemi and ask that toracat tells burakkucat what is the final outcome
(of what is likely to be an extended discussion process) once it has
been reached.
Over to toracat.
Alan.
More information about the elrepo
mailing list