<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 10/12/2012 01:44 AM, Dag Wieers wrote:
<blockquote
cite="mid:alpine.LRH.2.02.1210120031330.2736@pikachu.3ti.be"
type="cite"><br>
Ok, this boils down to having potentially 3 kernels installed
'kernel', 'kernel-lt' and 'kernel-ml'.</blockquote>
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. <br>
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.<br>
<br>
<br>
<blockquote
cite="mid:alpine.LRH.2.02.1210120031330.2736@pikachu.3ti.be"
type="cite"> 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 ?
<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<br>
<blockquote
cite="mid:alpine.LRH.2.02.1210120031330.2736@pikachu.3ti.be"
type="cite">
<blockquote type="cite">
<blockquote type="cite">> Besides, we do not influence when
a release becomes stable, and when it > not
<br>
> longer is updated. So keeping all under the generic
'mainline' brand is > much
<br>
> clearer.
<br>
</blockquote>
<br>
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
)
<br>
</blockquote>
<br>
The paragraph before we assumed people knew what they were doing,
and now we don't ?
<br>
<br>
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:
<br>
<br>
- 3.0 (at 3.0.45)
<br>
- 3.2 (at 3.2.31)
<br>
- 3.4 (at 3.4.13)
<br>
- 3.5 (at 3.5.6) -> ending
<br>
- 3.6 (at 3.6.1)
<br>
</blockquote>
You forgot 2.6.32 and 2.6.34 :) ..... Actually there are no less
than 8 trees marked as "stable" at <a class="moz-txt-link-abbreviated" href="http://www.kernel.org">www.kernel.org</a><br>
We are not discussing stability here ( we all <strike>presume</strike>
hope that the kernels that we get are stable, don't we? [*] ) but
long-term maintenance.<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:alpine.LRH.2.02.1210120031330.2736@pikachu.3ti.be"
type="cite">Stable release suddenly stop. Alan decides what
versions ELRepo provides, but 'kernel-lt' is a bit shortsighted
IMHO.
<br>
<br>
Besides, what is confusing are 2-letter acronyms. Tell me, what is
more confusing, one 2-letter acronym, or two, or four ?
<br>
</blockquote>
Fine. Then let's call it kernel-mainline-supported-until-2014
instead of kernel-lt :)<br>
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.<br>
<br>
<br>
manuel<br>
<br>
<br>
* about stability:
<a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=863422">https://bugzilla.redhat.com/show_bug.cgi?id=863422</a><br>
</body>
</html>