On 12/10/12 17:44, Dag Wieers wrote:
On Fri, 12 Oct 2012, Akemi Yagi wrote:
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.
So, with the risk of beating a dead horse, I discussed the issues that I
think are valid with Akemi on IRC. In the end it is up to Alan and the
community to decide what direction to go, but I want to make sure we
make a decision to change for the right reasons.
Alan only really ever wanted to do one kernel - the latest upstream
kernel. The folks at kernel.org refer to that release as the mainline
kernel hence Alan called his kernel package kernel-ml.
I later tried to persuade Alan that it might be useful to also keep the
current "longterm" kernel (again a kernel.org term) as at the time Alan
was having a few issues transitioning to the latest 3.0 numbering. My
reasoning was that it was a) a newer kernel than the distro kernel, and
b) as it had long term support from kernel.org it was something we could
offer with some consistency during periods when packages for the latest
mainline kernel were being developed (although these days Alan seems to
be able to knock out the latest releases with amazing speed).
As there are really only ever two kernels on offer (mainline and
longterm), to me it makes perfect sense to name them accordingly. What
"version" or branch they are from is largely irrelevant. Those running
kernel-ml can expect yum to deliver the very latest kernel to their
system (be it 3.4, 3.5, 3.6 ...) whereas those running the longterm
kernel can expect yum to deliver the latest updates to that kernel
(currently 3.0.y) for as long as kernel.org supports it (currently to a
minimum of Jan 2014). To me that is the essence of what we (or rather
Alan) is offering.
My main objection to Dag's proposal is due to the frequency that new
kernels are released upstream. With new branches released every 6-8
weeks we'd constantly be creating new directory structures and updating
elrepo-release to reflect that. If new releases were ~ once per year,
maybe, but the current upstream release cycle is just way to frequent
for this method to be efficient IMHO.
I also believe it adds unnecessary complexity - the main problem it
seems to be trying to solve is allowing a user to stay on an unsupported
(by kernel.org) release (say 3.5) when the user could just as easily
achieve this by adding an exclude to prevent the package being updated
any more once they reach a position where the latest release may no
longer work for them. This is pretty much standard practice for any
broken package IMHO and doesn't warrant the creation of separate
repositories.
The decision to change is driven purely by user requests/expectations
that yum can/will update within the current 3.0.y "longterm" branch
rather than update from that to the latest mainline branch as it does
now. Either of the proposed methods solves the problem at hand, but I
believe the renaming route offers the best solution for the reasons I've
outlined.
Phil
_______________________________________________
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo
