[elrepo] kernel/kernel-lts separation

[Akemi Yagi]

On Fri, Oct 12, 2012 at 8:20 AM, Phil Perry <phil at elrepo.org> wrote:
> On 12/10/12 16:01, Dag Wieers wrote:
>>
>> On Thu, 11 Oct 2012, Akemi Yagi wrote:

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

Having understood the subdirectory method, I now say I'd prefer the
kernel-ml / kernel-lt option for 2 reasons.

One is that, as Phil said, having to update the elrepo-release package
because of kernel addition does not sound right. We want to keep it as
static as we can.

Second is from the users point of view. With the split method one
would install elrepo kernel by running:

yum --enablerepo=elrepo-kernel kernel-ml
or
yum --enablerepo=elrepo-kernel kernel-lt

The choice remains between the two as the kernel version advances,
which I think makes it easy for the users.

Akemi