hi guys,
We are still in the early days of CentOS-6, and perhaps a change in policy at this time might be acceptable. I'd like to propose moving the CR repo into the mainline repos. So the change I'm proposing is :
- to have a /6/ release that is always updated.
- to have the /6.X/ releases that are contained to within that point release
what this means is that /6/ will point at the most recent release of 6.X/ for the os/ & isos/ repo. The other repos would be local to the /6/ symlink, and will be always updated ( and stay that way ).
there is going to be quite a lot of implications backend / mirror side that we will need to work out, but its effort + pain as a one off, for what can be a major improvement in the user experience.
thoughts ?
- KB
Hi.
I agree. I think there is no added value to this seperate repo. Besides it is stalling new releases coming out sooner. +1
Regards, Marko On Tue, 1 Nov 2011, Karanbir Singh wrote:
hi guys,
We are still in the early days of CentOS-6, and perhaps a change in policy at this time might be acceptable. I'd like to propose moving the CR repo into the mainline repos. So the change I'm proposing is :
to have a /6/ release that is always updated.
to have the /6.X/ releases that are contained to within that point release
what this means is that /6/ will point at the most recent release of 6.X/ for the os/ & isos/ repo. The other repos would be local to the /6/ symlink, and will be always updated ( and stay that way ).
there is going to be quite a lot of implications backend / mirror side that we will need to work out, but its effort + pain as a one off, for what can be a major improvement in the user experience.
thoughts ?
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 11/01/2011 03:15 PM, Karanbir Singh wrote:
hi guys,
We are still in the early days of CentOS-6, and perhaps a change in policy at this time might be acceptable. I'd like to propose moving the CR repo into the mainline repos. So the change I'm proposing is :
- to have a /6/ release that is always updated.
I would welcome this very much, it makes my mirroring setup much easier in that I don't have to update it every time a 6.x release comes out (since I'm only interested in mirroring the latest release ofcourse)
On 11/01/2011 02:40 PM, Ferry Huberts wrote:
I would welcome this very much, it makes my mirroring setup much easier in that I don't have to update it every time a 6.x release comes out (since I'm only interested in mirroring the latest release ofcourse)
It is actually going to add a lot of complexity to the mirroring setup. There will no longer be consistent point release tree's, and the /6/ target will keep changing, all the time. So you will need to carry on mirroring the entire centos/6/ tree anyway
the exact mechanics of how we implement this would still need to be worked out.
- KB
On 11/01/2011 03:48 PM, Karanbir Singh wrote:
On 11/01/2011 02:40 PM, Ferry Huberts wrote:
I would welcome this very much, it makes my mirroring setup much easier in that I don't have to update it every time a 6.x release comes out (since I'm only interested in mirroring the latest release ofcourse)
It is actually going to add a lot of complexity to the mirroring setup. There will no longer be consistent point release tree's, and the /6/ target will keep changing, all the time. So you will need to carry on mirroring the entire centos/6/ tree anyway
the exact mechanics of how we implement this would still need to be worked out.
ok thanks.
(my mirror is just a rsync with a local ISP's mirror)
On 11/01/2011 02:53 PM, Ferry Huberts wrote:
the exact mechanics of how we implement this would still need to be worked out.
(my mirror is just a rsync with a local ISP's mirror)
In which case you should be ok to retain the existing targets etc, you will just need a bit more space to mirror into, quite a bit more space.
- KB
On 11/01/2011 10:48 AM, Karanbir Singh wrote:
On 11/01/2011 02:40 PM, Ferry Huberts wrote:
I would welcome this very much, it makes my mirroring setup much easier in that I don't have to update it every time a 6.x release comes out (since I'm only interested in mirroring the latest release ofcourse)
It is actually going to add a lot of complexity to the mirroring setup. There will no longer be consistent point release tree's, and the /6/ target will keep changing, all the time. So you will need to carry on mirroring the entire centos/6/ tree anyway
the exact mechanics of how we implement this would still need to be worked out.
- KB
Personally, I'd prefer to keep CR separate and have the main releases as they've been.
The idea behind CentOS is that it is super stable and matches upstream. I worry that merging CR will hurt the stability. I've enabled CR on some test nodes and started seeing issues, minor though they may be.
So +1 to keeping the status quo. :)
On 11/01/2011 03:47 PM, Digimer wrote:
Personally, I'd prefer to keep CR separate and have the main releases as they've been.
with the point release going into /6.x/ you will have the option to keep things as they are as well. Would that cover your use case ? it would allow you to do the point release switch manually, whenever you chose to do so.
The idea behind CentOS is that it is super stable and matches upstream. I worry that merging CR will hurt the stability. I've enabled CR on some test nodes and started seeing issues, minor though they may be.
I hope you are opening bug reports for these issues!
- KB
On 11/01/2011 11:50 AM, Karanbir Singh wrote:
On 11/01/2011 03:47 PM, Digimer wrote:
Personally, I'd prefer to keep CR separate and have the main releases as they've been.
with the point release going into /6.x/ you will have the option to keep things as they are as well. Would that cover your use case ? it would allow you to do the point release switch manually, whenever you chose to do so.
So long as I can do a 'yum update' and not get the next y-stream packages until the actual y-stream is released proper, I am happy. In other words, so long as the stability of my nodes is not effected in any way, and compatibility with upstream also remains, I am happy. :)
The idea behind CentOS is that it is super stable and matches upstream. I worry that merging CR will hurt the stability. I've enabled CR on some test nodes and started seeing issues, minor though they may be.
I hope you are opening bug reports for these issues!
I'm ashamed to say that I neglected to do so. I saw kernel oopses while working on other things and didn't get back to them... I'll be sure to file a bug next I see it.
On Tue, Nov 1, 2011 at 10:57 AM, Digimer linux@alteeve.com wrote:
So long as I can do a 'yum update' and not get the next y-stream packages until the actual y-stream is released proper,
But you also don't get potentially critical security updates until the full release. That is, yum update won't give you anything.
I am happy. In other words, so long as the stability of my nodes is not effected in any way, and compatibility with upstream also remains, I am happy. :)
What stability problems would you expect from updates beyond a point release? The whole point of an 'enterprise' distribution is the effort they make to not break api's across a whole major-rev's life. Would an upstream system break if you selectively update packages beyond a point release without doing a full update?
I'm ashamed to say that I neglected to do so. I saw kernel oopses while working on other things and didn't get back to them... I'll be sure to file a bug next I see it.
That's ummm, strange. Wouldn't you be running that kernel even if the whole release had been completed?
On 11/01/2011 12:19 PM, Les Mikesell wrote:
On Tue, Nov 1, 2011 at 10:57 AM, Digimer linux@alteeve.com wrote:
So long as I can do a 'yum update' and not get the next y-stream packages until the actual y-stream is released proper,
But you also don't get potentially critical security updates until the full release. That is, yum update won't give you anything.
Having critical updates available in CR gives me the opportunity to, when I deem it sufficiently critical, to manually pull the package (and it's dependencies) down *or* enabling the CR repo entirely.
I am happy. In other words, so long as the stability of my nodes is not effected in any way, and compatibility with upstream also remains, I am happy. :)
What stability problems would you expect from updates beyond a point release? The whole point of an 'enterprise' distribution is the effort they make to not break api's across a whole major-rev's life. Would an upstream system break if you selectively update packages beyond a point release without doing a full update?
As I mentioned earlier, after enabling CR I started seeing kernel oopses. I will need to be more diligent when I see the error next time and submit a bug report.
I'm ashamed to say that I neglected to do so. I saw kernel oopses while working on other things and didn't get back to them... I'll be sure to file a bug next I see it.
That's ummm, strange. Wouldn't you be running that kernel even if the whole release had been completed?
I really can't say, as I said, I wasn't sufficiently diligent at the time as I was fighting another fire. I do believe the kernel was upgraded when I went to the CR repo though. I'll build up another pair of machines and see if I can reproduce the issue tomorrow.
On Tuesday, November 01, 2011 12:19:31 PM Les Mikesell wrote:
What stability problems would you expect from updates beyond a point release? The whole point of an 'enterprise' distribution is the effort they make to not break api's across a whole major-rev's life. Would an upstream system break if you selectively update packages beyond a point release without doing a full update?
If the absolute ABI didn't occasionally break from upstream, Scientific Linux would likely not do point releases the way that they do them.
On Wed, Nov 2, 2011 at 10:38 AM, Lamar Owen lowen@pari.edu wrote:
On Tuesday, November 01, 2011 12:19:31 PM Les Mikesell wrote:
What stability problems would you expect from updates beyond a point release? The whole point of an 'enterprise' distribution is the effort they make to not break api's across a whole major-rev's life. Would an upstream system break if you selectively update packages beyond a point release without doing a full update?
If the absolute ABI didn't occasionally break from upstream, Scientific Linux would likely not do point releases the way that they do them.
What do you mean? They do point releases so you have the option to install something that is not horribly out of date. I thought they rolled out updates into the new point release as they built them, not waiting for a complete set and install media - and that they had always done it that way so there was no expectation of getting updates otherwise. That is, they set up the mechanism before anyone could know whether point releases would break working 3rd party binaries or not. But not having such breakage is the main reason to be running RHEL or a clone. If rebuilding from the stock source produces an incompatible binary, that is something else.
What stability problems would you expect from updates beyond a point release? The whole point of an 'enterprise' distribution is the effort they make to not break api's across a whole major-rev's life. Would an upstream system break if you selectively update packages beyond a point release without doing a full update?
Upstream backports big chunks of kernel code into point releases, changing the kernel api/abi. You'll notice this if you have special HPC hardware which need updated kernel modules. You'll also notice this if you really care about performance. We carefully test point-release kernels and only do casual testing of intermediate kernels, because the intermediate kernels are the only ones with small changes. (Ditto for HPC hardware vendors...)
Upstream sometimes does big updates of a few user-space rpms in point releases, because it has become too hard to backport security fixes. Firefix is a common example, and there are others. These sorts of changes usually don't happen in an intermediate update.
Upstream has never tested the combination of packages available in CR. It's easily possible that package A depends on package B being updated to avoid an obscure bug, but the CR only has A's update. Gentoo users are quite familiar with this issue.
It is likely that many CentOS users think they aren't bothered by these issues, but CentOS is used in a lot of production environments, and I bet there will be some surprises.
-- greg
p.s. Thanks for producing such a good distro!
On 11/18/2011 07:58 PM, Greg Lindahl wrote:
Upstream has never tested the combination of packages available in CR.
if you look at the rhn experience for most people - its actually quite in line with the CR/ process - as if it were just one release moving along with point-in-time install media being made available. Otoh, its been a long time since i did anything with rhn, have things changed ?
It's easily possible that package A depends on package B being updated to avoid an obscure bug, but the CR only has A's update. Gentoo users are quite familiar with this issue.
if CR/ was composed of every and all updates, would that issue be reduced to some extent ? completely removed ?
Also, keep in mind that people can opt out of the process and lock their machines into a point release ( eg. lock into 6.1, and only move to 6.2 when they want to ). So it would still be possible for people to control at that level. Its just that rather than this being the default, it becomes the opt-in process.
It is likely that many CentOS users think they aren't bothered by these issues, but CentOS is used in a lot of production environments, and I bet there will be some surprises.
Thats the thing we want to reduce.
- KB
On Sat, Nov 19, 2011 at 09:23:09PM +0000, Karanbir Singh wrote:
On 11/18/2011 07:58 PM, Greg Lindahl wrote:
Upstream has never tested the combination of packages available in CR.
if you look at the rhn experience for most people - its actually quite in line with the CR/ process - as if it were just one release moving along with point-in-time install media being made available. Otoh, its been a long time since i did anything with rhn, have things changed ?
Well, my experience (and I think this is fairly typical) is that I install all the updates soon after they arrive. So there's no way I could end up with a 6.0+6.0updates with a single 6.1 package, which is what CR is intended to do.
During the 5.X series, there was one time that I downgraded a package, expat, due to a bug that took Upstream a long time to fix. One.
Also, keep in mind that people can opt out of the process and lock their machines into a point release ( eg. lock into 6.1, and only move to 6.2 when they want to ).
Yes, of course, that's what I plan on doing.
Les Mikesell brings up the reasonable question of whether version dependencies might save the day. They probably will in most cases, but with both Gentoo and Debian, I have discovered enough errors in those dependencies that I don't expect Upstream to get this right, especially when almost all of their users aren't going to try to install a single 6.1 package on 6.0. I doubt I'll convice Les with this argument, but there you have it. As an Enterprise user, I'm not interested in experimenting with having most CentOS users do something that few Upstream users do. Baaaaah. Baaaaaah (baaaad sheep imitation.)
-- greg
On 11/19/2011 10:53 PM, Greg Lindahl wrote:
On Sat, Nov 19, 2011 at 09:23:09PM +0000, Karanbir Singh wrote:
On 11/18/2011 07:58 PM, Greg Lindahl wrote:
Upstream has never tested the combination of packages available in CR.
if you look at the rhn experience for most people - its actually quite in line with the CR/ process - as if it were just one release moving along with point-in-time install media being made available. Otoh, its been a long time since i did anything with rhn, have things changed ?
Well, my experience (and I think this is fairly typical) is that I install all the updates soon after they arrive. So there's no way I could end up with a 6.0+6.0updates with a single 6.1 package, which is what CR is intended to do.
Not sure where you got that. CR is intended to add many packages and distribute them more evenly throughout the point release creation process in a stage way.
Where the media set is not yet done for the future point release, but all the RPMs are in CR.
It allows us to prioritize building (get enough "dependencies" done and get the security updates out in the first batch and release them to CR ... then build all the other RPMs in the point release.
We can also build the updates for the next point release (some of the zero day ... also many Firefox, etc. come out) while we are still putting together the final point release media set.
It seems to me that you are arguing for a process that puts out staged sets of updates and then saying CR is bad (which is how we can do staged updates).
During the 5.X series, there was one time that I downgraded a package, expat, due to a bug that took Upstream a long time to fix. One.
Also, keep in mind that people can opt out of the process and lock their machines into a point release ( eg. lock into 6.1, and only move to 6.2 when they want to ).
Yes, of course, that's what I plan on doing.
Les Mikesell brings up the reasonable question of whether version dependencies might save the day. They probably will in most cases, but with both Gentoo and Debian, I have discovered enough errors in those dependencies that I don't expect Upstream to get this right, especially when almost all of their users aren't going to try to install a single 6.1 package on 6.0. I doubt I'll convice Les with this argument, but there you have it. As an Enterprise user, I'm not interested in experimenting with having most CentOS users do something that few Upstream users do. Baaaaah. Baaaaaah (baaaad sheep imitation.)
Again ... not sure what you think CR is.
CR is basically dumping all updates as we get them built and working into a repo that people can install in real time, instead of waiting a month (oe more) for every single update to complete before we release anything (our current practice). I am really failing to see how that is what you are talking about at all ... maybe I am lost.
On Sun, Nov 20, 2011 at 08:38:18AM -0600, Johnny Hughes wrote:
Again ... not sure what you think CR is.
CR is basically dumping all updates as we get them built and working into a repo that people can install in real time, instead of waiting a month (oe more) for every single update to complete before we release anything (our current practice). I am really failing to see how that is what you are talking about at all ... maybe I am lost.
That's exactly what I'm talking about. Sorry that I wasn't clear. Let me try again with an example:
Let's say that "foo" is one of the many packages updated in 6.1.
With CR, let's say that "foo" happens to be the first 6.1 package added to 6.0-CR.
When I install "foo" from 6.0-CR, I am now running a combination of 6.0 + a single 6.1 rpm. This combination has probably never been tested by upstream; almost all of the upstream people installed almost all of the new 6.1 rpms together.
I'm here posting about this issue because I'm responding to this question:
What stability problems would you expect from updates beyond a point release? The whole point of an 'enterprise' distribution is the effort they make to not break api's across a whole major-rev's life. Would an upstream system break if you selectively update packages beyond a point release without doing a full update?
The fact that upstream hasn't tested these rpm combinations means that there's risk involved.
-- greg
On Sun, Nov 20, 2011 at 3:32 PM, Greg Lindahl greg@blekko.com wrote:
I'm here posting about this issue because I'm responding to this question:
What stability problems would you expect from updates beyond a point release? The whole point of an 'enterprise' distribution is the effort they make to not break api's across a whole major-rev's life. Would an upstream system break if you selectively update packages beyond a point release without doing a full update?
The fact that upstream hasn't tested these rpm combinations means that there's risk involved.
Updates can't be tested against your local applications either - which is what you'd care most about. But the risk of breakage is small because upstream doesn't make changes that break API's as a matter of policy across major revisions - which is the whole point of 'enterprise' versions. If you don't change an API, you don't need to re-test against everything that uses it.
On Sun, Nov 20, 2011 at 06:27:46PM -0600, Les Mikesell wrote:
The fact that upstream hasn't tested these rpm combinations means that there's risk involved.
Updates can't be tested against your local applications either - which is what you'd care most about.
Well, if you recall what I wrote previously in the thread, I said that I tested my local applications carefully against point releases, and not that much against intermediate updates, which tend to be much smaller and less risky than the changes in the point releases.
With CR, I'd have to do a lot more testing.
If you don't change an API, you don't need to re-test against everything that uses it.
You saw my previous comments about how upstream _does_ change APIs, but seemingly only in point releases? For example, the InfiniBand stuff changed dramatically through the 5.X releases. Each time they'd backport a bunch of stuff into the kernel, and release matching userspace rpms.
Sorry to be repeating myself so much, but I think the point about when upstream makes bigger changes (point releases) is important for everyone to understand.
-- greg
On 11/20/2011 03:32 PM, Greg Lindahl wrote:
On Sun, Nov 20, 2011 at 08:38:18AM -0600, Johnny Hughes wrote:
Again ... not sure what you think CR is.
CR is basically dumping all updates as we get them built and working into a repo that people can install in real time, instead of waiting a month (oe more) for every single update to complete before we release anything (our current practice). I am really failing to see how that is what you are talking about at all ... maybe I am lost.
That's exactly what I'm talking about. Sorry that I wasn't clear. Let me try again with an example:
Let's say that "foo" is one of the many packages updated in 6.1.
With CR, let's say that "foo" happens to be the first 6.1 package added to 6.0-CR.
When I install "foo" from 6.0-CR, I am now running a combination of 6.0 + a single 6.1 rpm. This combination has probably never been tested by upstream; almost all of the upstream people installed almost all of the new 6.1 rpms together.
But, any combination of the released package set should work together (within the requires in the RPMs of course).
People update only a subset of packages all the time, mostly because of custom software that they have done themselves.
But I think I actually agree with one point you are making. I truly believe the CR should be exactly as it is now ... optional. If you want to use it, you can easily issue the command:
yum install centos-release-cr
And if you want to do it only as a released version (no CR), then that is OK too and it should be (IMHO) the default.
I'm here posting about this issue because I'm responding to this question:
What stability problems would you expect from updates beyond a point release? The whole point of an 'enterprise' distribution is the effort they make to not break api's across a whole major-rev's life. Would an upstream system break if you selectively update packages beyond a point release without doing a full update?
The fact that upstream hasn't tested these rpm combinations means that there's risk involved.
You are correct that some ABIs do change ... BUT ... in that case they will include that in the RPM by something like "xulrunner > X.Y.Z", then you can only install FOO if you meet the requirements. You absolutely should be able to install any installable combination that is not hard coded with a version in the requirements. If you can't then the RPM requirements are not properly programmed and it is a bug.
On Sun, Nov 20, 2011 at 4:32 PM, Greg Lindahl greg@blekko.com wrote:
When I install "foo" from 6.0-CR, I am now running a combination of 6.0 + a single 6.1 rpm. This combination has probably never been tested by upstream; almost all of the upstream people installed almost all of the new 6.1 rpms together.
I'm here posting about this issue because I'm responding to this question:
What stability problems would you expect from updates beyond a point release? The whole point of an 'enterprise' distribution is the effort they make to not break api's across a whole major-rev's life. Would an upstream system break if you selectively update packages beyond a point release without doing a full update?
The fact that upstream hasn't tested these rpm combinations means that there's risk involved.
FSVO risk, sure. Except that upstream recommends this all the time when troubleshooting customer systesms.
We have several systems deployed at customer sites that are RHEL 5.3... with the 5.6 glibc. And this was recommended by 3rd level support, not some 1st level person following a script.
Sure, I'd prefer to have 5.6 (or 5.7) on the systems, but they're on an isolated network scattered all over the globe physically, so doing that isn't very easy. And upstream understands this, as well as the desire from some customers to not change from a particular sub-version without cause. They may not have explicitly tested various package combinations, but the commitment to a stable API/ABI means that mixing packages from within the same major version number is safe with a small number of exceptions (which are in the tech notes).
IOW, the risk is exceptionally small.
Tom Sorensen
On 11/22/2011 10:43 AM, Tom Sorensen wrote:
FSVO risk, sure. Except that upstream recommends this all the time when troubleshooting customer systesms.
We have several systems deployed at customer sites that are RHEL 5.3... with the 5.6 glibc. And this was recommended by 3rd level support, not some 1st level person following a script.
Sure, I'd prefer to have 5.6 (or 5.7) on the systems, but they're on an isolated network scattered all over the globe physically, so doing that isn't very easy. And upstream understands this, as well as the desire from some customers to not change from a particular sub-version without cause. They may not have explicitly tested various package combinations, but the commitment to a stable API/ABI means that mixing packages from within the same major version number is safe with a small number of exceptions (which are in the tech notes).
IOW, the risk is exceptionally small.
With a nice support contract and an army of willing RH engineers on the other end of a phone, yes, the risk is small.
For $Johnny_webhost, who takes his daily income from his business, and can't afford the above mentioned support on his rack full of EL boxes (which is why he uses centos), he needs to balance the risk of losing customers due a security incident vs running a full up to date and stable system with a mix of current and upcoming release packages, and all with the knowledge in his head and what he can get from the main centos list (most of which last time I looked appeared to be a conversation about why you should use ubuntu over centos).
The Lowest Common Denominator is the one we need to think about here. The end user that wants EL stability and security, but can't afford to spend the money on upstream subscriptions.
On Mon, Nov 21, 2011 at 5:50 PM, Stephen Walsh steve@nerdvana.org.au wrote:
On 11/22/2011 10:43 AM, Tom Sorensen wrote:
FSVO risk, sure. Except that upstream recommends this all the time when troubleshooting customer systesms.
IOW, the risk is exceptionally small.
With a nice support contract and an army of willing RH engineers on the other end of a phone, yes, the risk is small.
And you are running the same code...
For $Johnny_webhost, who takes his daily income from his business, and can't afford the above mentioned support on his rack full of EL boxes (which is why he uses centos), he needs to balance the risk of losing customers due a security incident vs running a full up to date and stable system with a mix of current and upcoming release packages, and all with the knowledge in his head and what he can get from the main centos list (most of which last time I looked appeared to be a conversation about why you should use ubuntu over centos).
The Lowest Common Denominator is the one we need to think about here. The end user that wants EL stability and security, but can't afford to spend the money on upstream subscriptions.
The question is whether this person would be better off getting security updates that were built post-minor-rev-update or not in a default 'yum update'. It's a yes or no question, where recommending doing one thing and making the default something else doesn't make a lot of sense. With/without the CR approach, the non-security related updates are going to come along for the ride, and you will probably want them anyway.
On 11/21/2011 06:05 PM, Les Mikesell wrote:
On Mon, Nov 21, 2011 at 5:50 PM, Stephen Walsh steve@nerdvana.org.au wrote:
On 11/22/2011 10:43 AM, Tom Sorensen wrote:
FSVO risk, sure. Except that upstream recommends this all the time when troubleshooting customer systesms.
IOW, the risk is exceptionally small.
With a nice support contract and an army of willing RH engineers on the other end of a phone, yes, the risk is small.
And you are running the same code...
For $Johnny_webhost, who takes his daily income from his business, and can't afford the above mentioned support on his rack full of EL boxes (which is why he uses centos), he needs to balance the risk of losing customers due a security incident vs running a full up to date and stable system with a mix of current and upcoming release packages, and all with the knowledge in his head and what he can get from the main centos list (most of which last time I looked appeared to be a conversation about why you should use ubuntu over centos).
The Lowest Common Denominator is the one we need to think about here. The end user that wants EL stability and security, but can't afford to spend the money on upstream subscriptions.
The question is whether this person would be better off getting security updates that were built post-minor-rev-update or not in a default 'yum update'. It's a yes or no question, where recommending doing one thing and making the default something else doesn't make a lot of sense. With/without the CR approach, the non-security related updates are going to come along for the ride, and you will probably want them anyway.
BUT ... I think that giving the user the choice is certainly preferable. We have a process that we use to build and test packages, and when we finish we have what we call a stable and completely QA'ed process.
We offer, at some increased risk (due to less QA), a repo staged updates.
We made this very easy to get ... just run yum install centos-release-cr if you want it.
But we give the customer the option to take the increase risk or not.
I think this is the RIGHT way to do this.
I know that it means if you do not know how to manage your machine (and issue a very simple command to get CR) then you don't get it ... but I still think that the full repo with full QA should be the default.
We can recommend that people go ahead and do CR in the release notes, but I think it is a mistake to turn it on by default.
If you would rather add it to the MAIN rpeo file (CentOS-Base.repo) and have it off, then require people to edit that to get it, that is fine by me too ... but I think a simple command (yum install centos-release-cr) is much easier than editing the CentOS-Base.repo file anyway.
Then, we make people who want CR happy, they can install it and it works after install ... and we make the people like Greg happy because he does not have to do anything to turn it off if he perceives the risk is too great to have it on.
That way, we can recommend (through the release notes) that people use it ... but give them the final option.
That's my $0.02
Dne 22.11.2011 9:55, Johnny Hughes napsal(a):
We made this very easy to get ... just run yum install centos-release-cr if you want it.
But we give the customer the option to take the increase risk or not.
I think this is the RIGHT way to do this.
Johnny, CR repo is fine, glad we have it. I'd like it to stay optional. We are using it on boxes not managed by Spacewalk. Boxes managed by Spacewalk are not using CR: - no erratas (we are using errata binding) - packages from CR are going to be moved into Base/Updates repos, but Spacewalk server keeps all the downloaded packages
So, CR is good trade-off, full release would be better. Thanks, DH
On Tue, Nov 22, 2011 at 2:55 AM, Johnny Hughes johnny@centos.org wrote:
The question is whether this person would be better off getting security updates that were built post-minor-rev-update or not in a default 'yum update'. It's a yes or no question, where recommending doing one thing and making the default something else doesn't make a lot of sense. With/without the CR approach, the non-security related updates are going to come along for the ride, and you will probably want them anyway.
BUT ... I think that giving the user the choice is certainly preferable.
You have always had the choice of running 'yum update' or not. Or running it for specific packages. Or looking at the list it offers and making the choice then. That's for people who are paying attention. The question is what should happen if you don't pay attention and just expect 'yum update' to always install all available security updates for the life of the major rev like it always had before, dragging along some other bugfixes at minor releases.
We offer, at some increased risk (due to less QA), a repo staged updates.
I think the risk factor goes the other way, at least for any machine that needs updates at all. We just haven't had a well-known exploit to show it yet.
We made this very easy to get ... just run yum install centos-release-cr if you want it.
But we give the customer the option to take the increase risk or not.
That would be reduce the risk if any security issues are involved.
I think this is the RIGHT way to do this.
Maybe it would have been from the beginning, but at this point I'd bet that there are a lot of CentOS installations that haven't updated and don't know that they have to do something new and different to get security updates.
I know that it means if you do not know how to manage your machine (and issue a very simple command to get CR) then you don't get it ... but I still think that the full repo with full QA should be the default.
How long do you think it is reasonable to go without updates? I'd call it mostly a matter of luck if you keep running after any combination of a remote exploit plus a local privilege escalation are known by anyone - and that has always been just a matter of time.
Then, we make people who want CR happy, they can install it and it works after install ... and we make the people like Greg happy because he does not have to do anything to turn it off if he perceives the risk is too great to have it on.
If updating is too much of a risk, don't update at all. He's going to get the one he suggested as a problem as soon as you do a real release anyway. I don't think he really identified a problem related to having the minor rev updates come before a new anaconda/iso is available.
On 11/22/2011 08:04 AM, Les Mikesell wrote:
On Tue, Nov 22, 2011 at 2:55 AM, Johnny Hughes johnny@centos.org wrote:
The question is whether this person would be better off getting security updates that were built post-minor-rev-update or not in a default 'yum update'. It's a yes or no question, where recommending doing one thing and making the default something else doesn't make a lot of sense. With/without the CR approach, the non-security related updates are going to come along for the ride, and you will probably want them anyway.
BUT ... I think that giving the user the choice is certainly preferable.
You have always had the choice of running 'yum update' or not. Or running it for specific packages. Or looking at the list it offers and making the choice then. That's for people who are paying attention. The question is what should happen if you don't pay attention and just expect 'yum update' to always install all available security updates for the life of the major rev like it always had before, dragging along some other bugfixes at minor releases.
It still does, when we get the release done. We are not going to leave the stuff in CR forever. When the release happens, those people get the same pacakges as the last version of CR. So they will get the updates too.
We offer, at some increased risk (due to less QA), a repo staged updates.
I think the risk factor goes the other way, at least for any machine that needs updates at all. We just haven't had a well-known exploit to show it yet.
I don't know what to tell you ... it all comes down to choices. If you can't wait to get updates, Buy RHEL. If you don't want RHEL, you decide what YOU think is the riskiest situation. if you do nothing, centos works exactly like it does now.
Also, don't forget that we have made MAJOR changes to our build system and we are building things much more efficiently now than before.
We have also found and fixed several issues like these:
https://bugzilla.redhat.com/show_bug.cgi?id=641739
https://bugzilla.redhat.com/show_bug.cgi?id=743229
Which caused us many bad packages.
We made this very easy to get ... just run yum install centos-release-cr if you want it.
But we give the customer the option to take the increase risk or not.
That would be reduce the risk if any security issues are involved.
You have the option to get it if you want it or you can wait. If an update breaks your system because of a QA issue and causes you downtime, that is also a risk. The issue is, you (the user) get to decide .. not Johnny or Les, but the user.
I think this is the RIGHT way to do this.
Maybe it would have been from the beginning, but at this point I'd bet that there are a lot of CentOS installations that haven't updated and don't know that they have to do something new and different to get security updates.
They do not HAVE to do anything new. CR is an option thing that has a limited time scope. They will still get updates when we release the point release.
And judge us by the 6.2 release. It should happen soon and we now have finalized all our scripting for the new build system for 6.x. Of course, new issues will mean we need new scripts, but I think we have it working well now.
We are also expecting several very large build machines from 2 vary large sponsors .. I can't name them, but everyone knows them.
I know that it means if you do not know how to manage your machine (and issue a very simple command to get CR) then you don't get it ... but I still think that the full repo with full QA should be the default.
How long do you think it is reasonable to go without updates? I'd call it mostly a matter of luck if you keep running after any combination of a remote exploit plus a local privilege escalation are known by anyone - and that has always been just a matter of time.
You are in complete control of this ... we get done when we get done. If that is not fast enough for you, you must use something else. RHEL is available.
Then, we make people who want CR happy, they can install it and it works after install ... and we make the people like Greg happy because he does not have to do anything to turn it off if he perceives the risk is too great to have it on.
If updating is too much of a risk, don't update at all. He's going to get the one he suggested as a problem as soon as you do a real release anyway. I don't think he really identified a problem related to having the minor rev updates come before a new anaconda/iso is available.
Not necessarily. We have FIXED many issues from CR .. also even if they are not fixed, they are called out in bugs.centos.org ... like this one:
http://bugs.centos.org/view.php?id=5254
Easy enough to fix if you are expecting it ... someone in CR found it (also upstream).
The point is ... use CR or don't ... choice is yours. Use CentOS or RHEL ... that choice is also yours. If you want SLA level update times, you need an SLA level Enterprise Linux.
On 11/22/2011 08:29 AM, Johnny Hughes wrote:
....
Oh, and another thing. We are automating many processes in the QA system too...
https://gitorious.org/+centos-testing
Everyone can see tests and people who request to can create tests to help us check for things that we find are problems.
This process is getting better for 6.x
In case you have not noticed, all the updates for c5.x and c4.x have been happening within 24 hours (the within a point release updates).
Things are getting better, not worse.
On Tue, 22 Nov 2011, Johnny Hughes wrote:
Things are getting better, not worse.
Noted and appreciated. Thank you, Johnny, and the CentOS team, for working hard on this, in spite of upstream making it more difficult to do these quickly!
******************************************************************************* Gilbert Sebenste ******** (My opinions only!) ****** Staff Meteorologist, Northern Illinois University **** E-mail: sebenste@weather.admin.niu.edu *** web: http://weather.admin.niu.edu ** Twitter: http://www.twitter.com/NIU_Weather ** Facebook: http://www.facebook.com/niu.weather * *******************************************************************************
On 11/22/2011 08:04 AM, Les Mikesell wrote:
On Tue, Nov 22, 2011 at 2:55 AM, Johnny Hughes johnny@centos.org wrote:
The question is whether this person would be better off getting security updates that were built post-minor-rev-update or not in a default 'yum update'. It's a yes or no question, where recommending doing one thing and making the default something else doesn't make a lot of sense. With/without the CR approach, the non-security related updates are going to come along for the ride, and you will probably want them anyway.
BUT ... I think that giving the user the choice is certainly preferable.
You have always had the choice of running 'yum update' or not. Or running it for specific packages. Or looking at the list it offers and making the choice then. That's for people who are paying attention. The question is what should happen if you don't pay attention and just expect 'yum update' to always install all available security updates for the life of the major rev like it always had before, dragging along some other bugfixes at minor releases.
I've always thought if you are aware enough that you are selective about updates and concerned about breakage of your dependencies (be they ABI, API, or otherwise), you'd review the release notes of every package before updating anything and stage updates into a testing environment before moving them to production, regardless of whether the updates come via CR.
In that case, if the CR is rolled into a mainline continuous distribution by default, you'd still be selectively choosing your updates based on what they do, rather than blindly installing them and assuming they won't break everything.
If the user is too novice to care or know better, he is going to blindly do this either before or after the full QA process. In my experience so far with the CR, there have been no significant QA problems with packages. Changes upstream that break compatibility will arrive either way for most people and not rolling them continuously just delays security fixes and the compatibility breakage until an arbitrary future time, which really doesn't save anyone any headaches.
Not only that, but even within a release of EL5, there have been updates which had serious operational consequences, such as the openssl renegotiation patch, which changed application behavior in occasionally incompatible ways.
All other things equal, I'd always rather err on the side of a system service going offline due to a dependency break than exploited due to an unpatched security vulnerability.
Well my 5c...nothing beeing wrong with CR repo but does it not upstream provider(RH) deploys updates as they come? so if you put them as you compile them in the main Repo it would be the same? :) (maybe just chech the order...)
Regards, Marko On Tue, 22 Nov 2011, Les Mikesell wrote:
On Tue, Nov 22, 2011 at 2:55 AM, Johnny Hughes johnny@centos.org wrote:
The question is whether this person would be better off getting security updates that were built post-minor-rev-update or not in a default 'yum update'. It's a yes or no question, where recommending doing one thing and making the default something else doesn't make a lot of sense. With/without the CR approach, the non-security related updates are going to come along for the ride, and you will probably want them anyway.
BUT ... I think that giving the user the choice is certainly preferable.
You have always had the choice of running 'yum update' or not. Or running it for specific packages. Or looking at the list it offers and making the choice then. That's for people who are paying attention. The question is what should happen if you don't pay attention and just expect 'yum update' to always install all available security updates for the life of the major rev like it always had before, dragging along some other bugfixes at minor releases.
We offer, at some increased risk (due to less QA), a repo staged updates.
I think the risk factor goes the other way, at least for any machine that needs updates at all. We just haven't had a well-known exploit to show it yet.
We made this very easy to get ... just run yum install centos-release-cr if you want it.
But we give the customer the option to take the increase risk or not.
That would be reduce the risk if any security issues are involved.
I think this is the RIGHT way to do this.
Maybe it would have been from the beginning, but at this point I'd bet that there are a lot of CentOS installations that haven't updated and don't know that they have to do something new and different to get security updates.
I know that it means if you do not know how to manage your machine (and issue a very simple command to get CR) then you don't get it ... but I still think that the full repo with full QA should be the default.
How long do you think it is reasonable to go without updates? I'd call it mostly a matter of luck if you keep running after any combination of a remote exploit plus a local privilege escalation are known by anyone - and that has always been just a matter of time.
Then, we make people who want CR happy, they can install it and it works after install ... and we make the people like Greg happy because he does not have to do anything to turn it off if he perceives the risk is too great to have it on.
If updating is too much of a risk, don't update at all. He's going to get the one he suggested as a problem as soon as you do a real release anyway. I don't think he really identified a problem related to having the minor rev updates come before a new anaconda/iso is available.
Vreme: 11/22/2011 09:00 PM, Marko Bevc piše:
Well my 5c...nothing beeing wrong with CR repo but does it not upstream provider(RH) deploys updates as they come? so if you put them as you compile them in the main Repo it would be the same? :) (maybe just chech the order...)
2c -> 5c Inflation already? ;-)
You probably haven't read the whole thread. They are discussing possible changes in ABI, API... that upstream performs at point releases 5.6, 5.7, ... compared to Continuous Repo without expected breakage at point-release release time.
You better pedal back 35+ messages and track down particular point of discussion before you respond, if you do not understand what I wrote just now.
Sorry...must have missed all that mails :D Well as said before it is always your choice to run yum update - and that way we can preserve original procedure of RH distro ;)
Regards, Marko
On Tue, 22 Nov 2011, Ljubomir Ljubojevic wrote:
Vreme: 11/22/2011 09:00 PM, Marko Bevc piše:
Well my 5c...nothing beeing wrong with CR repo but does it not upstream provider(RH) deploys updates as they come? so if you put them as you compile them in the main Repo it would be the same? :) (maybe just chech the order...)
2c -> 5c Inflation already? ;-)
You probably haven't read the whole thread. They are discussing possible changes in ABI, API... that upstream performs at point releases 5.6, 5.7, ... compared to Continuous Repo without expected breakage at point-release release time.
You better pedal back 35+ messages and track down particular point of discussion before you respond, if you do not understand what I wrote just now.
On Tue, Nov 22, 2011 at 3:00 PM, Marko Bevc marko@bevc.net wrote:
Well my 5c...nothing beeing wrong with CR repo but does it not upstream provider(RH) deploys updates as they come?
No. I don't know where people got this idea that RH delivers that way.
When 6.2 comes out (any day now) all of the rpms will be made available at that time. None of the rpms are pushed into the channel prior to that.
And unless you do some special foo in RHN your systems will pull down all of those updates next time you do a "yum update" on them. Or you can push them to the system from RHN. That makes it no different from what happens when CentOS makes a point release.
The CR repo is quite different from how RH does it. As I stated earlier I don't think that there's any significant danger (particularly compared to having no security updates for months, as is the current situation with 6) from trickling in RPMs, but it *is* different from upstream.
Tom Sorensen
On Tue, Nov 22, 2011 at 11:27 PM, Tom Sorensen wrote:
When 6.2 comes out (any day now) all of the rpms will be made available at that time. None of the rpms are pushed into the channel prior to that.
And unless you do some special foo in RHN your systems will pull down all of those updates next time you do a "yum update" on them. Or you can push them to the system from RHN. That makes it no different from what happens when CentOS makes a point release.
Yes, but after upstream 6.2 has been released you could also run an update command that is not a fully update, but something like
yum update foo_package
And this command will pull in what is required by rpm configuration in spec file for foo package + its sub-dependencies. So, also with upstream, you could be at a certain time, in a mixed 6.1 + 6.2 level, no guarantee And for sure upstream can't test every combination of foo update that doesn't imply the whole 6.2 tree changes applied to your system...
This to say that if CentOS provides an updated package in CR with all its dependencies we will get the same effect as we would get in upstream. If CentOS makes a package foo publicly available but forgets one of its dependencies (from an rpm chain point of view) you will get an error when you run the yum command. (a part from yum/rpm bugs themselves)
Said that, I vote (if I can) for having CR optional and enabled manually by the user as it is now.
Thanks Gianluca
Am 22.11.2011 um 23:58 schrieb Gianluca Cecchi:
On Tue, Nov 22, 2011 at 11:27 PM, Tom Sorensen wrote:
When 6.2 comes out (any day now) all of the rpms will be made available at that time. None of the rpms are pushed into the channel prior to that.
And unless you do some special foo in RHN your systems will pull down all of those updates next time you do a "yum update" on them. Or you can push them to the system from RHN. That makes it no different from what happens when CentOS makes a point release.
Yes, but after upstream 6.2 has been released you could also run an update command that is not a fully update, but something like
yum update foo_package
And this command will pull in what is required by rpm configuration in spec file for foo package + its sub-dependencies. So, also with upstream, you could be at a certain time, in a mixed 6.1
- 6.2 level, no guarantee
- your scenario would end up in a 6.2 system.
- the description "mixed" misdescribes the actual process
- not all rpms will be updated in a point release.
- a virgin 6.2 installation will install (for sure) a rpm that also exists in a virgin 6.1 installation.
the point is - that this "mixed" combination is a valid one (validated by upstream).
if the are any dependencies - the "requires/provides" internals of the package system will push the necessary packages.
by the way - CentOS is explicitly taking care of this linking libs and symbols and etceteras
And for sure upstream can't test every combination of foo update that doesn't imply the whole 6.2 tree changes applied to your system...
This to say that if CentOS provides an updated package in CR with all its dependencies we will get the same effect as we would get in upstream. If CentOS makes a package foo publicly available but forgets one of its dependencies (from an rpm chain point of view) you will get an error when you run the yum command. (a part from yum/rpm bugs themselves)
Said that, I vote (if I can) for having CR optional and enabled manually by the user as it is now.
me too
__ LF
On Wed, Nov 23, 2011 at 3:28 PM, Leon Fauster wrote:
your scenario would end up in a 6.2 system.
the description "mixed" misdescribes the actual process
the point is - that this "mixed" combination is a valid one (validated by upstream).
if the are any dependencies - the "requires/provides" internals of the package system will push the necessary packages.
Hi Leon, actually I have not understood if you agreed with me or not (a part the vote... ;-) This is what I mean with "mixed environment" and what I tested (considered 5.6 --> 5.7 instead of 6.1 --> 6.2)
- install base system from rh 5.6 x86_64 dvd iso [root@rh56 ~]# uname -r 2.6.18-238.el5
[root@rh56 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.6 (Tikanga)
- register the server with rhn
- update some packages [root@rh56 ~]# yum update yum ... Updated: yum.noarch 0:3.2.22-37.el5
Complete!
[root@rh56 ~]# yum update glibc ... Updated: glibc.i686 0:2.5-65 glibc.x86_64 0:2.5-65
Dependency Updated: glibc-common.x86_64 0:2.5-65 glibc-devel.i386 0:2.5-65 glibc-devel.x86_64 0:2.5-65 glibc-headers.x86_64 0:2.5-65 nscd.x86_64 0:2.5-65
Complete!
[root@rh56 ~]# yum update kernel ... Installed: kernel.x86_64 0:2.6.18-274.7.1.el5
Complete!
[root@rh56 ~]# yum update redhat-release ... Updated: redhat-release.x86_64 0:5Server-5.7.0.3
[root@rh56 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.7 (Tikanga)
- reboot [root@rh56 ~]# uname -r 2.6.18-274.7.1.el5
[root@rh56 ~]# rpm -qa|wc -l 442
So, after a pure rh e 5.6 install l I then directly updated 10 packages from rh el 5.7+updates bandwagon... While the other 432 packages remained as stock rh el 5.6 original dvd
This is what I call a mixed environment.... Note that if I run [root@rh56 ~]# yum update I'm proposed this: ... Transaction Summary ======================= Install 1 Package(s) Upgrade 140 Package(s)
Total download size: 116 M Is this ok [y/N]: Exiting on user Command Complete!
Is this supported by upstream? I think so. And the same process would be with CentOS supposing they provided in CR repo the 10 packages above (actually 9, considering redhat-release that doesn't carry on any dependencies btw....)
Hope that this explains better my point about mixed-environment, and the final system not being a 5.7 installation...
Gianluca
Hi Gianluca,
Am 23.11.2011 um 16:39 schrieb Gianluca Cecchi:
On Wed, Nov 23, 2011 at 3:28 PM, Leon Fauster wrote:
your scenario would end up in a 6.2 system.
the description "mixed" misdescribes the actual process
the point is - that this "mixed" combination is a valid one (validated by upstream).
if the are any dependencies - the "requires/provides" internals of the package system will push the necessary packages.
actually I have not understood if you agreed with me or not (a part the vote... ;-) This is what I mean with "mixed environment" and what I tested (considered 5.6 --> 5.7 instead of 6.1 --> 6.2)
<snip>...</snip>
So, after a pure rh e 5.6 install l I then directly updated 10 packages from rh el 5.7+updates bandwagon... While the other 432 packages remained as stock rh el 5.6 original dvd
This is what I call a mixed environment....
i agree with you :-)
To evaluate the implications of the CR repo - like it is or as a default repo - i suggest to define some major scenarios. The way people use yum update-commands explicitly/manually will be always a continuous spectrum (also included: across more then one releases e.g. "5.3... with the 5.6 glibc").
One scenario would be - a system that has CR enabled and therefore is in a state that i call e.g "6.(coming release)" minus packages that are not already build.
One such state was mentioned in this thread. A full updated system with one (expat) package downgraded. This example had an issue but not as result of a continuous update.
If there are any real issues - i would like to compile them. Even the mentioned kernel oops could have there cause elsewhere.
One good thing to keep in mind - the CR rpms passes through a "stable and completely QA'ed process".
Is this supported by upstream? I think so.
I would say by design. If a point releases is out (upstream) - the CR repo is able to provide a package with ALL necessary rpms that resolves the corresponding dependencies.
Even if kernel-updates of point releases change api's, the dependencies of userspace (kernel) packages should reflect necessary requirements.
And the same process would be with CentOS supposing they provided in CR repo the 10 packages above (actually 9, considering redhat-release that doesn't carry on any dependencies btw....)
thats it.
I understand the mentioned stability hints of some people. I just want to show up that a reasonable assessment must include the context. We are not speaking about fedora or other quite interesting distros (as already mentioned) but about an enterprise distro. This means, it is fairly stable over the whole lifecycle (centos way to build the distro included).
(Example: Even if a major update is done (php 5.1 -> 5.3) the "enterprise focus" forces upstream to provide this update as option.
Hope that this explains better my point about mixed-environment, and the final system not being a 5.7 installation...
Sure - and i didn't explain my point of view correctly.
The above is more technicaly. The essential question can not be answered here. Anyone have to consider there own underlying conditions. Centos can only offer the options as needed (e.g. CR as option).
That's my EUR 0.01
-- LF
On Fri, Nov 18, 2011 at 1:58 PM, Greg Lindahl greg@blekko.com wrote:
What stability problems would you expect from updates beyond a point release? The whole point of an 'enterprise' distribution is the effort they make to not break api's across a whole major-rev's life. Would an upstream system break if you selectively update packages beyond a point release without doing a full update?
Upstream has never tested the combination of packages available in CR. It's easily possible that package A depends on package B being updated to avoid an obscure bug, but the CR only has A's update. Gentoo users are quite familiar with this issue.
Version dependencies are supposed to be noted in the rpms and this isn't gentoo - the apis aren't generally supposed to be changing at all or you couldn't expect your own and 3rd party applications to continue to run.
It is likely that many CentOS users think they aren't bothered by these issues, but CentOS is used in a lot of production environments, and I bet there will be some surprises.
I've fairly routinely updated individual packages only across minor rev changes or held some back without problems. Your argument would be more convincing if you had several examples of update combinations not prevented by package dependencies that will break something.
It looks like there is need in little clarification / saying it more clear
Vreme: 11/01/2011 03:15 PM, Karanbir Singh piše:
hi guys,
We are still in the early days of CentOS-6, and perhaps a change in policy at this time might be acceptable. I'd like to propose moving the CR repo into the mainline repos. So the change I'm proposing is :
- to have a /6/ release that is always updated.
Does this means CR packages would go into updates repo? I use ISO = os repo, + updates repo, for mirroring.
- to have the /6.X/ releases that are contained to within that point release
So in 6.1 would go all CR packages and further updates until 6.2 packages?
what this means is that /6/ will point at the most recent release of 6.X/ for the os/& isos/ repo. The other repos would be local to the /6/ symlink, and will be always updated ( and stay that way ).
there is going to be quite a lot of implications backend / mirror side that we will need to work out, but its effort + pain as a one off, for what can be a major improvement in the user experience.
thoughts ?
- KB
On Tue, Nov 1, 2011 at 10:15 AM, Karanbir Singh mail-lists@karan.org wrote:
what this means is that /6/ will point at the most recent release of 6.X/ for the os/ & isos/ repo. The other repos would be local to the /6/ symlink, and will be always updated ( and stay that way ).
Just so I have it straight:
- OS won't change from the way it is handled today - Updated packages between point releases still go to Updates - Packages that are part of the next point release (that are going into CR now) will instead go into Updates under the new plan - When a point release comes out, OS changes to the new point release and Updates gets a cleanup to remove CR and Updates that are part of the new point release - Cycle repeats
It seems to me that as long as you are doing any network installs just from the OS tree, it shouldn't change from the way it is today. Under the new plan, everyone is basically opting in to receive the CR updates. I assume the comments about needing more space to mirror is because the CR tree basically replaces a large portion of the OS tree?
On 11/01/2011 09:15 AM, Karanbir Singh wrote:
hi guys,
We are still in the early days of CentOS-6, and perhaps a change in policy at this time might be acceptable. I'd like to propose moving the CR repo into the mainline repos. So the change I'm proposing is :
to have a /6/ release that is always updated.
to have the /6.X/ releases that are contained to within that point release
what this means is that /6/ will point at the most recent release of 6.X/ for the os/ & isos/ repo. The other repos would be local to the /6/ symlink, and will be always updated ( and stay that way ).
there is going to be quite a lot of implications backend / mirror side that we will need to work out, but its effort + pain as a one off, for what can be a major improvement in the user experience.
I am absolutely in favor of a "continuous release" CentOS 6 that's permanent. For a lot of CentOS users, I think there's no real advantage to holding back between minor versions and this avoids the need for users to knowingly opt-in to retain access to constant security updates.
We don't really need updated media since our kickstart files always just pull in the updates repo (and now CR also). Updated media as a slower process in the background is fine with my company.
As a mirror we certainly have the space to do this. I would hope this can be done with hard-linking to reduce the space demands on others where space is more of an issue.
-
David Hrbáč -
Digimer -
Ferry Huberts -
Gianluca Cecchi -
Gilbert Sebenste -
Greg Lindahl -
Johnny Hughes -
Karanbir Singh -
Kevin Stange -
Lamar Owen -
Leon Fauster -
Les Mikesell -
Ljubomir Ljubojevic -
Marko Bevc -
Stephen Walsh -
Tom Sorensen -
William Hooper