[elrepo] kernel/kernel-lts separation

[Phil Perry]

On 12/10/12 16:01, Dag Wieers wrote:
> On Thu, 11 Oct 2012, Akemi Yagi wrote:
>
>> On Thu, Oct 11, 2012 at 2:23 PM, Dag Wieers <dag at wieers.com> wrote:
>>
>>> 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.
>>
>> I am trying to understand this concept of "sub-repositories". Using
>> the above example, Elrepo will be offering new repositories named
>> "kernel-ml-3.0" and "kernel-ml-3.8" ? When a user wants to install a
>> 3.0.x kernel, he will run:
>>
>> yum --enablerepo=kernel-ml-3.0 install kernel-ml
>>
>> And when a new major version appears, it will be added as, say,
>> "kernel-ml-3.9" and the elrepo-release package is updated to
>> accommodate the new repository.
>>
>> Is this description correct?
>
> Yes, so the repo configuration could offer the root-directory
> (kernel-ml) as well as the subdirectories (kernel-ml-3.0, kernel-ml-3.6)
> and it's up to the user to decide which one to enable. By default (as is
> now) all repositories are disabled.
>
> Since the sub-directories are inside of the root kernel-ml directory,
> all packages are included in the kernel-ml repository. The selection of
> which stable release you want to hook into is made at the
> repository-level. So the added benefit is that you could possibly stay
> with 3.0, even when 3.2 or 3.4 are available, or discontinued.
>
> For those interested in getting the latest kernel-ml, they simply enable
> the root repository as is already the case.
>
> The drawback is that if the 3.0 repository is no longer updated (because
> upstream discontinued support) the user will not receive newer updates.
> In the kernel-lt mechanism, you cannot make the selection to which
> stable release you want to hook into, as all kernel-ml and kernel-lt
> packages are in one repository (as I understood) so you always get the
> latest (either kernel-ml or kernel-lt, or both).
>
> Another drawback is that the ELRepo configuration should reflect the
> repositories we offer, so a change is required if there is a change in
> what we offer.
>

Having looked at both options, I'm personally preferring renaming and 
having two separate packages, kernel-ml and kernel-lt.

I think it will be easier to explain to end users, requires no real 
configuration on the part of the end user and doesn't require us to push 
out updates to our elrepo-release file, which inevitably not everyone 
will update.

JMHO :-)