On 10/12/2012 01:44 AM, Dag Wieers wrote:
Ok, this boils down to having potentially 3 kernels installed
'kernel', 'kernel-lt' and 'kernel-ml'.
You are perfectly correct here, potentially, yes, all three variants
could be installed in the same time. But OTOH the kernel-lt is intended
for people who do not want the latest major version so probably they
would not install kernel-ml in the same time. I assume ( but of course,
I might be wrong) that people would chose between these two lines of
kernels depending on their intent.
However I really do not see the problem here. Yes, if one decides to
install more than one kernel variant, one has to take care of all. Just
like it would do with a single one. By definition all the kernels coming
from elrepo come with a disclaimer. Which will affect all kernels that
do not come from main+updates. no matter if there is one or there are
more variants.
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 ?
The difference between -lt and -ml boils down to the difference that
kernel.org makes between stable and long-term. And making sure that
during an update ( a simple yum update, not necessarily a yum update
kernel-ml ) the higher versioned kernel-ml packages would not
inadvertently remove the lower-versioned-but-fancied-by-the-admin
version. The name change is just a way of helping users to use the 3.0
line without forcing them to use specific includes/excludes in the repo
definition files.
> 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)
You forgot 2.6.32 and 2.6.34 :) ..... Actually there are no less than 8
trees marked as "stable" at www.kernel.org
We are not discussing stability here ( we all presume hope that the
kernels that we get are stable, don't we? [*] ) but long-term maintenance.
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 ?
Fine. Then let's call it kernel-mainline-supported-until-2014 instead of
kernel-lt :)
Seriously speaking now, that's why we are discussing. kernel-lts was
suggested as a name exactly because LTS already has a known connotation.
Your idea of creating sub-repositories is a possible alternative. I do
not like it ( just like I hated the two sets of php packages from
dev.centos.org ... nobody knew how to get them ) but that's just me.
Let's hear other opinions as well.
manuel
* about stability: https://bugzilla.redhat.com/show_bug.cgi?id=863422
_______________________________________________
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
