On 10/12/2012 12:44 AM, Alan Bartlett wrote:
On 11 October 2012 22:23, Dag Wieers<d...@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.
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 )
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.
I find the idea of adding subrepos the most inconvenient of all
approaches suggested so far.
_______________________________________________
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
