Re: [elrepo] kernel/kernel-lts separation
On 14.10.2012 17:57, Akemi Yagi wrote: OK, I blame the whole mess on Nux! who started this damn thing. ;-) I deny everything! We will adopt the kernel-ml/kernel-lt naming for the mainline/longterm kernels. No objections allowed at this point ! Akemi the Despot Wow, thank you very much, Akemi-sama! And thanks in advance to Alan for all the work implied! -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On 12/10/12 16:01, Dag Wieers wrote: On Thu, 11 Oct 2012, Akemi Yagi wrote: On Thu, Oct 11, 2012 at 2:23 PM, Dag Wieers d...@wieers.com wrote: 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. I am trying to understand this concept of sub-repositories. Using the above example, Elrepo will be offering new repositories named kernel-ml-3.0 and kernel-ml-3.8 ? When a user wants to install a 3.0.x kernel, he will run: yum --enablerepo=kernel-ml-3.0 install kernel-ml And when a new major version appears, it will be added as, say, kernel-ml-3.9 and the elrepo-release package is updated to accommodate the new repository. Is this description correct? Yes, so the repo configuration could offer the root-directory (kernel-ml) as well as the subdirectories (kernel-ml-3.0, kernel-ml-3.6) and it's up to the user to decide which one to enable. By default (as is now) all repositories are disabled. Since the sub-directories are inside of the root kernel-ml directory, all packages are included in the kernel-ml repository. The selection of which stable release you want to hook into is made at the repository-level. So the added benefit is that you could possibly stay with 3.0, even when 3.2 or 3.4 are available, or discontinued. For those interested in getting the latest kernel-ml, they simply enable the root repository as is already the case. The drawback is that if the 3.0 repository is no longer updated (because upstream discontinued support) the user will not receive newer updates. In the kernel-lt mechanism, you cannot make the selection to which stable release you want to hook into, as all kernel-ml and kernel-lt packages are in one repository (as I understood) so you always get the latest (either kernel-ml or kernel-lt, or both). Another drawback is that the ELRepo configuration should reflect the repositories we offer, so a change is required if there is a change in what we offer. Having looked at both options, I'm personally preferring renaming and having two separate packages, kernel-ml and kernel-lt. I think it will be easier to explain to end users, requires no real configuration on the part of the end user and doesn't require us to push out updates to our elrepo-release file, which inevitably not everyone will update. JMHO :-) ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
I have considered everyone's comments, including that from Trevor. On the whole, I am agreeable with making the split into kernel-ml (currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6. How would people like this to be implemented? Alan. ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On Thu, Oct 11, 2012 at 1:34 PM, Alan Bartlett a...@elrepo.org wrote: I have considered everyone's comments, including that from Trevor. On the whole, I am agreeable with making the split into kernel-ml (currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6. How would people like this to be implemented? Alan. Simply have both in the elrepo-kernel repository? Akemi ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On 11.10.2012 21:48, Akemi Yagi wrote: On Thu, Oct 11, 2012 at 1:34 PM, Alan Bartlett a...@elrepo.org wrote: I have considered everyone's comments, including that from Trevor. On the whole, I am agreeable with making the split into kernel-ml (currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6. How would people like this to be implemented? Alan. Simply have both in the elrepo-kernel repository? Yep, should work fine. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On 11.10.2012 21:34, Alan Bartlett wrote: I have considered everyone's comments, including that from Trevor. On the whole, I am agreeable with making the split into kernel-ml (currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6. Thank you! -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On 10/11/2012 11:48 PM, Akemi Yagi wrote: On Thu, Oct 11, 2012 at 1:34 PM, Alan Bartletta...@elrepo.org wrote: I have considered everyone's comments, including that from Trevor. On the whole, I am agreeable with making the split into kernel-ml (currently 3.6.x) and kernel-lt (currently 3.0.y) for EL6. How would people like this to be implemented? Alan. Simply have both in the elrepo-kernel repository? +1 for this ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
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. 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. Is there a need for the proposed complexity ? -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
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. 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. 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? Perhaps the simplest thing is for me is to type: No. No change. No nothing. No further releases from me. I've shown you all how to do it, now get on with it yourselves. :-) But I won't. I will hand the decision process over to my number two, Akemi and ask that toracat tells burakkucat what is the final outcome (of what is likely to be an extended discussion process) once it has been reached. Over to toracat. Alan. ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On Thu, 11 Oct 2012, 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. 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. 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? I didn't know complexity was a boolean. ;-) The proposal was to add repositories and change the package name. I don't see a good reason for the second change, in fact I see many reason to not make the second change. -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On 10/10/2012 11:09 AM, Nux! wrote: Hi, Guys, is there a possibility to have the TLS kernels in their own repo or would it be just spreading too thin? Maybe some hardlinks as to not waste space.. I'm not using the lts kernel but I'm thinking many do and they don't want to have the lts kernel updated by the latest one. I know people who run kernel-ml should only be using it with --enablerepo anyway, but oh well, the idea just hit me so had to share. :-) +1 here. not that LTS means much when 3.0.x was updated twice in 2 weeks... ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On 10.10.2012 09:12, Manuel Wolfshant wrote: On 10/10/2012 11:09 AM, Nux! wrote: Hi, Guys, is there a possibility to have the TLS kernels in their own repo or would it be just spreading too thin? Maybe some hardlinks as to not waste space.. I'm not using the lts kernel but I'm thinking many do and they don't want to have the lts kernel updated by the latest one. I know people who run kernel-ml should only be using it with --enablerepo anyway, but oh well, the idea just hit me so had to share. :-) +1 here. not that LTS means much when 3.0.x was updated twice in 2 weeks... It's not clear what you're +1 for. :) Regarding LTS, I would imagine the updates were nothing major, it's normal to get updates, just nothing that would break existing abi/api etc. Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On 10.10.2012 11:28, Phil Perry wrote: How about kernel-ml and kernel-lts for mainline and lts kernels, respectively. But even that gets complicated as it looks like Alan is currently maintaining 3.0, 3.5 and 3.6 branches. Still, renaming the 3.0.x packages to kernel-lts would at least differentiate between the LTS release and other mainline/stable releases and would allow yum to continue to update the LTS kernel series from within the same repo. Yeah, Alan's opinion is the one that should matter most so let's see what he thinks of it. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On 10/11/2012 12:57 AM, Alan Bartlett wrote: So let's try to move this on. As it is currently my move, I shall confirm that I am prepared to smile at the suggestion of kernel-lt and kernel-ml. To begin with, I would need to perform a small operation upon a copy of the kernel-ml specification file to create that of kernel-lt. Perhaps others will now like to think things through to completion. The only other modification I would see as needed [ for almost any other package but kernels ] would be Obsoletes: kernel-ml 3.0.45. But since kernels are parallel installable, I do not see anything else that needs to be done via the spec except for replacing the old Provides ( kernel-ml) with the new one. Then the ELRepo Project Administrators can have a private discussion and, ultimately, share the results of our deliberations with the user-base. Thank you ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On 10/10/12 23:23, Manuel Wolfshant wrote: On 10/11/2012 12:57 AM, Alan Bartlett wrote: So let's try to move this on. As it is currently my move, I shall confirm that I am prepared to smile at the suggestion of kernel-lt and kernel-ml. To begin with, I would need to perform a small operation upon a copy of the kernel-ml specification file to create that of kernel-lt. Perhaps others will now like to think things through to completion. The only other modification I would see as needed [ for almost any other package but kernels ] would be Obsoletes: kernel-ml 3.0.45. But since kernels are parallel installable, I do not see anything else that needs to be done via the spec except for replacing the old Provides ( kernel-ml) with the new one. Agreed. It should just be a case of performing a 's/kernel-ml/kernel-lt/' on the spec file for version 3.0.y. The hard work is already done by Alan in initially producing kernel-ml. ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
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? ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
Re: [elrepo] kernel/kernel-lts separation
On 11.10.2012 00:17, 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. +1 -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ___ elrepo mailing list elrepo@lists.elrepo.org http://lists.elrepo.org/mailman/listinfo/elrepo
