[elrepo] kernel/kernel-lts separation

[Dag Wieers]

On Fri, 12 Oct 2012, Manuel Wolfshant wrote:

> On 10/12/2012 12:44 AM, 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.
>
> That is mostly true. But since these packages are intended for people who 
> know what they do, not regular centos/rh users, I do not think that this 
> matters. This kind of people should either know how to read or stick to doing 
> something else.

Ok, this boils down to having potentially 3 kernels installed 'kernel', 
'kernel-lt' and 'kernel-ml'. If you switch from one to the other you have 
to manage those sets of packages. For 'kernel' I don't care, that's 
upstreamn, but what's the added benefit of having kernel-lt and kernel-ml ?

Even for people who know what they're doing ?


>> >  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.
>
> I beg to differ. When time comes we can simply switch to kernel-lt-4.0.1 
> instead of 3.0.x. Keeping ALL kernels below the kernel-ml generic name is 
> exactly the thing which would confuse potential users looking for the 'long 
> term stable' version ( whatever version the upstream kernel.org people decide 
> it to be )

The paragraph before we assumed people knew what they were doing, and now 
we don't ?

But that's not how it works. Stable kernels come and go, you have a few of 
those stable kernels in parallel. That's what the upstream kernel.org 
people have decided. Currently the following stable trees exist:

  - 3.0 (at 3.0.45)
  - 3.2 (at 3.2.31)
  - 3.4 (at 3.4.13)
  - 3.5 (at 3.5.6) -> ending
  - 3.6 (at 3.6.1)

Stable release suddenly stop. Alan decides what versions ELRepo provides, 
but 'kernel-lt' is a bit shortsighted IMHO.

Besides, what is confusing are 2-letter acronyms. Tell me, what is more 
confusing, one 2-letter acronym, or two, or four ?


>> >  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?
> The basic idea was to make choice easier by using a different name. 
> Separating the so called long-term packages in a different [sub]repo does not 
> achieve this  goal.

Sure it does. You subscribe to a repositoriy, and that's what you pull.


> I find the idea of adding subrepos the most inconvenient of all approaches 
> suggested so far.

Fair enough, I have nothing to add.


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