Following the strong recommendation on the CentOS-announce mailing list, we had added the centos-release-cr package to our kickstart for PXE based installs. Since the release of 5.7, this kickstart fails since the centos-release-cr package can no longer be found.
Given that there is a 5.7/cr directory, it appears the plans include having CR being an on-going convention rather than a on-time thing just for 5.7. If I understand this correctly that CR will be used again once upstream releases 5.8, then I would like to be able to leave centos-release-cr as part of my kickstart so it is already configured for the next batch of CR updates.
Is it possible to add centos-release-cr to the 5.7/cr sometime soon?
Also, on a somewhat related issue, is there a reason why this is not an single noarch package?
Thanks
Am 15.09.2011 03:13, schrieb Ben Galliart:
Following the strong recommendation on the CentOS-announce mailing list, we had added the centos-release-cr package to our kickstart for PXE based installs. Since the release of 5.7, this kickstart fails since the centos-release-cr package can no longer be found.
Given that there is a 5.7/cr directory, it appears the plans include having CR being an on-going convention rather than a on-time thing just for 5.7. If I understand this correctly that CR will be used again once upstream releases 5.8, then I would like to be able to leave centos-release-cr as part of my kickstart so it is already configured for the next batch of CR updates.
Is it possible to add centos-release-cr to the 5.7/cr sometime soon?
The centos-cr repository should only be unsed during transition phase from one minor to another. The package will be removed once the next minor is release, and re-appear on next transition. (hope I said it right, Karan :))
So the cr release package is not meant to be included in kickstart by default.
Greets Marcus
On Thu, Sep 15, 2011 at 11:34 AM, Marcus Moeller wrote:
The centos-cr repository should only be unsed during transition phase from one minor to another. The package will be removed once the next minor is release, and re-appear on next transition. (hope I said it right, Karan :))
So the cr release package is not meant to be included in kickstart by default.
Based on this, I would expect an update from a 5.6 cr enabled server to 5.7 to remove/disable it. Instead I see both the rpm installed and repository still enabled... Do I have to manually operate in some way?
Gianluca
Am 15.09.2011 um 11:34 schrieb Marcus Moeller:
Am 15.09.2011 03:13, schrieb Ben Galliart:
Following the strong recommendation on the CentOS-announce mailing list, we had added the centos-release-cr package to our kickstart for PXE based installs. Since the release of 5.7, this kickstart fails since the centos-release-cr package can no longer be found.
Given that there is a 5.7/cr directory, it appears the plans include having CR being an on-going convention rather than a on-time thing just for 5.7. If I understand this correctly that CR will be used again once upstream releases 5.8, then I would like to be able to leave centos-release-cr as part of my kickstart so it is already configured for the next batch of CR updates.
Is it possible to add centos-release-cr to the 5.7/cr sometime soon?
The centos-cr repository should only be unsed during transition phase from one minor to another. The package will be removed once the next minor is release, and re-appear on next transition. (hope I said it right, Karan :))
So the cr release package is not meant to be included in kickstart by default.
Well, why not - if i'm doing an installation while the distribution is in transition phase?
The mentioned "remove" is done by the changing symlink (eg. 5 -> 5.6 changed to 5 -> 5.7).
By doing this, the cr repo target is then changed automagically to the new cr directory (yum/cr-repo-file looks only for $releasever).
If so - a generic centos-release-cr-5.el5.centos rpm would do the work (what it does already).
-- LF
By the way - the cr rpm is arch specific but that is not necessary because the distinguishing $basearch entry.
On 09/15/2011 12:34 PM, Marcus Moeller wrote:
Am 15.09.2011 03:13, schrieb Ben Galliart:
Following the strong recommendation on the CentOS-announce mailing list, we had added the centos-release-cr package to our kickstart for PXE based installs. Since the release of 5.7, this kickstart fails since the centos-release-cr package can no longer be found.
Given that there is a 5.7/cr directory, it appears the plans include having CR being an on-going convention rather than a on-time thing just for 5.7. If I understand this correctly that CR will be used again once upstream releases 5.8, then I would like to be able to leave centos-release-cr as part of my kickstart so it is already configured for the next batch of CR updates.
Is it possible to add centos-release-cr to the 5.7/cr sometime soon?
The centos-cr repository should only be unsed during transition phase from one minor to another. The package will be removed once the next minor is release, and re-appear on next transition. (hope I said it right, Karan :))
This was the first approach but it was changed. The implemented approach is for /cr to remain in place, the repository links from the repo definition will point to the new URL automatically. However the repository will be populated only during the transition phase of a new minor release ( i.e for instance after RHEL 5.8 is out but before CentOS 5.8 is released ).
So the cr release package is not meant to be included in kickstart by default.
that is true. It is useful only during the transitional phase between RHEL's launch of a new dot release and CentOS catching up.
On 09/15/2011 12:18 PM, Manuel Wolfshant wrote:
On 09/15/2011 12:34 PM, Marcus Moeller wrote:
The centos-cr repository should only be unsed during transition phase from one minor to another. The package will be removed once the next minor is release, and re-appear on next transition. (hope I said it right, Karan :))
This was the first approach but it was changed. The implemented approach is for /cr to remain in place, the repository links from the repo definition will point to the new URL automatically. However the repository will be populated only during the transition phase of a new minor release ( i.e for instance after RHEL 5.8 is out but before CentOS 5.8 is released ).
So the cr release package is not meant to be included in kickstart by default.
that is true. It is useful only during the transitional phase between RHEL's launch of a new dot release and CentOS catching up.
What's wrong with always having the CR repo installed and enabled ? It might be empty outside of transition periods, but this shouldn't hurt, right ? My understanding is there is no QA difference between a package pushed to the updates or one pushed to the cr repo, thus base + updates + cr repos should stack up nicely.
Regards, Xavier
On 09/15/2011 01:34 PM, Xavier Bachelot wrote:
On 09/15/2011 12:18 PM, Manuel Wolfshant wrote:
On 09/15/2011 12:34 PM, Marcus Moeller wrote:
The centos-cr repository should only be unsed during transition phase from one minor to another. The package will be removed once the next minor is release, and re-appear on next transition. (hope I said it right, Karan :))
This was the first approach but it was changed. The implemented approach is for /cr to remain in place, the repository links from the repo definition will point to the new URL automatically. However the repository will be populated only during the transition phase of a new minor release ( i.e for instance after RHEL 5.8 is out but before CentOS 5.8 is released ).
So the cr release package is not meant to be included in kickstart by default.
that is true. It is useful only during the transitional phase between RHEL's launch of a new dot release and CentOS catching up.
What's wrong with always having the CR repo installed and enabled ? It might be empty outside of transition periods, but this shouldn't hurt, right ?
right. the reported issue here is that they are trying to import the centos-cr package via the kickstart and there is no such package yet in CentOS 5.7
My understanding is there is no QA difference between a package pushed to the updates or one pushed to the cr repo, thus base + updates
- cr repos should stack up nicely.
that is correct. Actually the process is quite simple, packages are first pushed to the CentOS X.n/cr/ and then hardlinked to the Centos X.n+1/os ( or /updates, depending on the origin)
On Thu, Sep 15, 2011 at 12:51 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
My understanding is there is no QA difference between a package pushed to the updates or one pushed to the cr repo, thus base + updates
- cr repos should stack up nicely.
that is correct. Actually the process is quite simple, packages are first pushed to the CentOS X.n/cr/ and then hardlinked to the Centos X.n+1/os ( or /updates, depending on the origin) _______________________________________________
One could download the 5.6 cr package centos-release-cr-5-6.el5.centos.1.x86_64.rpm and put it inside a local server from where to get and install during kickstart post section. But I think that it would work during installation of a 5.6 system, but not work during an installation of a 5.7 system, as the command "rpm -qR centos-release-cr" says:
centos-release = 5-6.el5.centos.1 config(centos-release-cr) = 10:5-6.el5.centos.1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Correct?
Could it be made a general package in the name (centos-release-cr) and contain centos-release >= 5-6.el5.centos.1 ? Don't know about config(centos-release-cr) = 10:5-6.el5.centos.1 requirement meaning though...
Gianluca
On 09/15/2011 12:51 PM, Manuel Wolfshant wrote:
On 09/15/2011 01:34 PM, Xavier Bachelot wrote:
On 09/15/2011 12:18 PM, Manuel Wolfshant wrote:
On 09/15/2011 12:34 PM, Marcus Moeller wrote:
The centos-cr repository should only be unsed during transition phase from one minor to another. The package will be removed once the next minor is release, and re-appear on next transition. (hope I said it right, Karan :))
This was the first approach but it was changed. The implemented approach is for /cr to remain in place, the repository links from the repo definition will point to the new URL automatically. However the repository will be populated only during the transition phase of a new minor release ( i.e for instance after RHEL 5.8 is out but before CentOS 5.8 is released ).
So the cr release package is not meant to be included in kickstart by default.
that is true. It is useful only during the transitional phase between RHEL's launch of a new dot release and CentOS catching up.
What's wrong with always having the CR repo installed and enabled ? It might be empty outside of transition periods, but this shouldn't hurt, right ?
right. the reported issue here is that they are trying to import the centos-cr package via the kickstart and there is no such package yet in CentOS 5.7
Great, so this should be easily fixable once we've reached a consensus this package is needed even for otherwise empty centos/x.y/cr. Count me as +1 for this.
As a workaround for the possibly missing package in the kickstart, one can still add the '--ignoremissing' option to the %package directive.
My understanding is there is no QA difference between a package pushed to the updates or one pushed to the cr repo, thus base + updates
- cr repos should stack up nicely.
that is correct. Actually the process is quite simple, packages are first pushed to the CentOS X.n/cr/ and then hardlinked to the Centos X.n+1/os ( or /updates, depending on the origin)
Thanks for your answer.
Regards, Xavier
From Marcus Moeller: The centos-cr repository should only be unsed during transition phase from one minor to another. The package will be removed once the next minor is release, and re-appear on next transition. (hope I said it right, Karan :))
So the cr release package is not meant to be included in kickstart by default.
If CR is the recommended way to get security fixes during transition periods, then I would prefer to have systems opt-in ahead of time during the installs instead of at the last minute.
It seems odd to "strongly recommend everyone using CentOS-5 install and update their system using this repository" but then say it shouldn't be part of a kickstart. Is it recommended to install using the repo or not?
It also discourages use of the CR repo if the official method of using the repo only is provided when the distribution version is in transition. Most users are expecting the output of "yum update" to reflect if there is additional updates available for their system. It seems like users are now expected to also manually track the CentOS twitter page for additional instructions or availability of a repo release RPM. If that is the case, then to avoid confusion when yum normally would show no updates available, maybe yum should be modified to also provide details from Twitter as to what additional update steps are available and when.
Hi,
On 09/16/2011 01:54 AM, Ben Galliart wrote:
If CR is the recommended way to get security fixes during transition periods, then I would prefer to have systems opt-in ahead of time during the installs instead of at the last minute.
The /CR/ repo is meant to be an opt-in repository. The thinking is that once someone opts into the idea of what the CR repo is, they stay with it till such time as they want to opt-out, and they can do that with a rpm -e centos-release-cr.
imho, it would be wrong to force people to get the centos-release-cr by default, specially in the centos-5 lifecycle since it would be a drastic change in the way things work and what people's expectations might be.[1]
If there is a desire to have this be default behaviour then the split should, again imho - and open to discussion, be at the ReleaseVersion level - as implemented in the yum client interface and delivered via the mirrorlist / mirror network. To expand on that, using CentOS-6 as an example:
- change mirror.centos.org/centos/6/ to _be_ CR; ie, the updates/ repo under there would inherit the CR content automagically, and deliver repo metadata to cover all ( CentOS-6 os) + ( CentOS-6 updates ) released rpms. Would be tricky handling the /6/os/ repo, but we can work something out.
- change mirror.centos.org/centos/6.0/ to only deliver content that is 6.0 specific, ie: what we do now with a point release. /6.0/os would reflect install media shipped as CentOS-6.0-*bin*.iso; with /6.0/updates/ only delivering updates released during the 6.0/ cycle.
Now back to the question on hand, centos-release-cr in 5.7..
Perhaps the best place for the centos-release-cr is in the updates/ repo, rather than the /cr/ repo, since that way it would further reduce the barrier for people to opt-in, a simple 'yum install centos-releae-cr' would get them on the track, and keep them there till such time as they want to opt-out.
The important bit being that we keep the CR repo opt-in, and do our best to create awareness of this repository, what it hopes to achieve and how people can get it installed on their machines.
In terms of install-time-availability, we only really QA with the OS repo's; adding or removing other repos is left upto site specific implementations. However, if the centos-release-cr rpm was available in the updates/ repo, it would clear this issue up for you ( I'm presuming that you install with the updates/ repo present with a --repo line in your kickstart ).
Now w.r.t release version of centos-release-cr, its at 5-6.el5.centos since that reflects the state of CR. So you can see what condition of the machine is. Even if you were to install centos-release-cr today, it should still be 5-6.el5.centos since that was the last cr/ repo populated. With the first rpm release into 5.7/cr/ would come the centos-release-5-7.el5.centos rpm; which should get updated to everyone who has opted-in, and would then correctly reflect the status of the machine ( in that there would be a centos-release-5-7 and a centos-release-cr-5-7 ).
Is this version scheme causing more confusion than its clearing out ? Should there be a centos-release-cr-5-7.el5.centos available *NOW* in 5.7/cr/ and in 5.7/updates/ ?
- KB
[1]: Maybe we got the name wrong, NextRelease might have been clearer on the goals and deliverables of that repo rather than ContinuousRelease. And be easier to spell too :)
On Sep 17, 2011 11:24 AM, "Karanbir Singh" mail-lists@karan.org wrote:
imho, it would be wrong to force people to get the centos-release-cr by default, specially in the centos-5 lifecycle since it would be a drastic change in the way things work and what people's expectations might be.[1]
Sorry, but I don't know any people who expected the default Centos update behavior to lag months behind upstream for security fixes.
The important bit being that we keep the CR repo opt-in, and do our best to create awareness of this repository, what it hopes to achieve and how people can get it installed on their machines.
How does it make sense to recommend one thing and make the default something else? Especially when the default is not what people expect?
From Karanbir Singh: Now back to the question on hand, centos-release-cr in 5.7..
Perhaps the best place for the centos-release-cr is in the updates/ repo, rather than the /cr/ repo, since that way it would further reduce the barrier for people to opt-in, a simple 'yum install centos-releae-cr' would get them on the track, and keep them there till such time as they want to opt-out.
Yes, that is the type of solution I am looking for!
The important bit being that we keep the CR repo opt-in, and do our best to create awareness of this repository, what it hopes to achieve and how people can get it installed on their machines.
I understand the desire to keep the CR repo for opt-in. I would like to see it as easy as possible to perform the opt-in. If it could be provided as a noarch package in the update repo then it will be much easier to instruct users to install via rpm or yum.
Now w.r.t release version of centos-release-cr, its at 5-6.el5.centos since that reflects the state of CR. So you can see what condition of the machine is. Even if you were to install centos-release-cr today, it should still be 5-6.el5.centos since that was the last cr/ repo populated. With the first rpm release into 5.7/cr/ would come the centos-release-5-7.el5.centos rpm; which should get updated to everyone who has opted-in, and would then correctly reflect the status of the machine ( in that there would be a centos-release-5-7 and a centos-release-cr-5-7 ).
Is this version scheme causing more confusion than its clearing out ?
If the 5.6/CR packages where based on Upstream 5.7 packages then it would make more sense to me that it would be called 5-7. Likewise, if the 5.7/CR directory is planned to contain packages based on Upstream 5.8 then it would make more sense to me that it would be called 5-8. However, I feel this point is nitpicking and can live with the current version system.
Should there be a centos-release-cr-5-7.el5.centos available *NOW* in 5.7/cr/ and in 5.7/updates/ ?
I would like to see a centos-release-cr-5-8.el5.centos.noarch.rpm in 5.7/updates to allow users to clearly pre-opt-in now for packages based on Upstream 5.8 when they become available.
[1]: Maybe we got the name wrong, NextRelease might have been clearer on the goals and deliverables of that repo rather than ContinuousRelease. And be easier to spell too :)
I think now that "CR" has been used it will just create more confusion to change it. I personally would have picked PR (Pre-Release).
On 09/17/2011 01:23 PM, Karanbir Singh wrote:
imho, it would be wrong to force people to get the centos-release-cr by default, specially in the centos-5 lifecycle since it would be a drastic change in the way things work and what people's expectations might be.[1]
I honestly don't think that most users of CentOS have or should have the expectation they are going to stay with 5.6, for example, when 5.7 comes out, for security reasons and also because yum forces their upgrade. The RPM repos are replaced with new repos upon release, which don't retain the versions of packages that were available in previous releases. It's not really viable to stay on 5.6, and current operations assume you won't.
The only real way a user of "yum" can tell is that they suddenly receive a new "centos-release" package in their update.
If there is a desire to have this be default behaviour then the split should, again imho - and open to discussion, be at the ReleaseVersion level - as implemented in the yum client interface and delivered via the mirrorlist / mirror network. To expand on that, using CentOS-6 as an example:
- change mirror.centos.org/centos/6/ to _be_ CR; ie, the updates/ repo
under there would inherit the CR content automagically, and deliver repo metadata to cover all ( CentOS-6 os) + ( CentOS-6 updates ) released rpms. Would be tricky handling the /6/os/ repo, but we can work something out.
- change mirror.centos.org/centos/6.0/ to only deliver content that is
6.0 specific, ie: what we do now with a point release. /6.0/os would reflect install media shipped as CentOS-6.0-*bin*.iso; with /6.0/updates/ only delivering updates released during the 6.0/ cycle.
I am generally in favor of having a constantly rolling release at 5/ and 6/ instead of worrying about having the media ready. The vast majority of our installations are going to be updated from one release (5.6) to the next (5.7) and we perform PXE-based KS installs with the intention of having them start out fully updated.
If I never saw another ISO produced again, it would not be a problem for how I use CentOS, and I certainly think that getting new installs rolling on new media is of much less importance than keeping existing installs secure and stable.
As far as the content at 6/, I see the following making sense as a release process:
1) Upstream releases 6.1 2) All important update packages are produced and placed in 6/updates/ 3) While updates continue, 6.1 installer, images undergo QA and release 4) Full release tree is inserted at 6.1/ 5) Upon release, packages shared between 6/updates and 6.1/os are hardlinked together 6) After some mirror stabilization, 6/os is symlinked to 6.1/os 7) After another mirror stabilization 6/updates is cleared of pre-6.1 packages 8) After the usual waiting period, trees for 6.0 are moved to the vault and deleted from mirrors.
I would say that default installation $releasever should resolve to "6" and as usual, if there's a desire to fear any future 6.x releases, that's an exercise to be undertaken manually.
Now back to the question on hand, centos-release-cr in 5.7..
Perhaps the best place for the centos-release-cr is in the updates/ repo, rather than the /cr/ repo, since that way it would further reduce the barrier for people to opt-in, a simple 'yum install centos-releae-cr' would get them on the track, and keep them there till such time as they want to opt-out.
This is, as I had suggested on IRC, what I would prefer.
The important bit being that we keep the CR repo opt-in, and do our best to create awareness of this repository, what it hopes to achieve and how people can get it installed on their machines.
We provide supported "managed" Linux, so we want this to CR to always be enabled so that users get the expected result that if they update their system manually, they get security updates, and if we update, we don't have to worry about the opt-in process.
In terms of install-time-availability, we only really QA with the OS repo's; adding or removing other repos is left upto site specific implementations. However, if the centos-release-cr rpm was available in the updates/ repo, it would clear this issue up for you ( I'm presuming that you install with the updates/ repo present with a --repo line in your kickstart ).
Yes, I think a fully up-to-date installation is one of the primary goals of having the CR included in the kickstart.
Now w.r.t release version of centos-release-cr, its at 5-6.el5.centos since that reflects the state of CR. So you can see what condition of the machine is. Even if you were to install centos-release-cr today, it should still be 5-6.el5.centos since that was the last cr/ repo populated. With the first rpm release into 5.7/cr/ would come the centos-release-5-7.el5.centos rpm; which should get updated to everyone who has opted-in, and would then correctly reflect the status of the machine ( in that there would be a centos-release-5-7 and a centos-release-cr-5-7 ).
I'd say the version number is unimportant since the actual repo configuration is not version-dependent, so centos-release-cr-5-100 would be fine to avoid any possible confusion.
On 09/17/2011, Karanbir Singh wrote:
Now back to the question on hand, centos-release-cr in 5.7..
Perhaps the best place for the centos-release-cr is in the updates/ repo, rather than the /cr/ repo, since that way it would further reduce the barrier for people to opt-in, a simple 'yum install centos-releae-cr' would get them on the track, and keep them there till such time as they want to opt-out.
Is there any ETA as to when this could be done or at least decided on?
Thanks
On 09/22/2011 08:16 PM, Ben Galliart wrote:
On 09/17/2011, Karanbir Singh wrote:
Now back to the question on hand, centos-release-cr in 5.7..
Perhaps the best place for the centos-release-cr is in the updates/ repo, rather than the /cr/ repo, since that way it would further reduce the barrier for people to opt-in, a simple 'yum install centos-releae-cr' would get them on the track, and keep them there till such time as they want to opt-out.
Is there any ETA as to when this could be done or at least decided on?
There is no need to upgrade anything. If you installed the package, you are on CR ... then and now.
The CentOS-CR repo points to /5/cr/ (which is 5.7 now and was 5.6 when the repo file was released).
It (/cr/) is currently empty because 5.7/os and 5.7/updates contain all the RPMS that are required to update from 5.6 (or any other version of CentOS).
When 5.8 is released, the RPMs that are part of 5.8 will get put into the /5.7/cr/ and allow people who are opted in to get the updates before the 5.8 release.
I think maybe putting the RPM in "extras", so it is easier to install is doable ... but not a huge issue.
In fact, I have put it there. centos-release-cr is now in extras.
You can install it from there once the mirrors sync it up.
On 09/23/2011 03:25 PM, Johnny Hughes wrote:
On 09/22/2011 08:16 PM, Ben Galliart wrote:
On 09/17/2011, Karanbir Singh wrote:
Now back to the question on hand, centos-release-cr in 5.7..
Perhaps the best place for the centos-release-cr is in the updates/ repo, rather than the /cr/ repo, since that way it would further reduce the barrier for people to opt-in, a simple 'yum install centos-releae-cr' would get them on the track, and keep them there till such time as they want to opt-out.
Is there any ETA as to when this could be done or at least decided on?
There is no need to upgrade anything. If you installed the package, you are on CR ... then and now.
The CentOS-CR repo points to /5/cr/ (which is 5.7 now and was 5.6 when the repo file was released).
It (/cr/) is currently empty because 5.7/os and 5.7/updates contain all the RPMS that are required to update from 5.6 (or any other version of CentOS).
When 5.8 is released, the RPMs that are part of 5.8 will get put into the /5.7/cr/ and allow people who are opted in to get the updates before the 5.8 release.
We already understand clearly what CR is, I don't understand why every time we mention ideas for changes to the CR someone feels the need to explain how it's supposed to work.
We were trying to effect a change to ensure that a fresh, clean install of CentOS (any 5 release) could be pre-opted-in to CR before it actually has packages in it, simply by including centos-release-cr in %packages in our KS file (and whatever repo to pull the RPM from).
I think maybe putting the RPM in "extras", so it is easier to install is doable ... but not a huge issue.
It had been suggested to put it into updates/ (by KB) but extras/ works as well. As long as that RPM is in a repo which is enabled by default. Now you can update your CR instructions to say "yum install centos-release-cr" to opt-in instead of having them copy a URL and manually run "rpm -i"
In fact, I have put it there. centos-release-cr is now in extras.
You can install it from there once the mirrors sync it up.
That was the point, thank you. Please try to make sure that the CR repo file is placed in extras/ during the initial release of each new revision of CentOS to avoid breaking KS files that might want to pre-opt-in.
Johnny Hughes wrote on 09/23/2011 04:25 PM: ...
There is no need to upgrade anything. If you installed the package, you are on CR ... then and now.
The CentOS-CR repo points to /5/cr/ (which is 5.7 now and was 5.6 when the repo file was released).
It (/cr/) is currently empty because 5.7/os and 5.7/updates contain all the RPMS that are required to update from 5.6 (or any other version of CentOS).
When 5.8 is released, the RPMs that are part of 5.8 will get put into the /5.7/cr/ and allow people who are opted in to get the updates before the 5.8 release.
I think maybe putting the RPM in "extras", so it is easier to install is doable ... but not a huge issue.
In fact, I have put it there. centos-release-cr is now in extras.
You can install it from there once the mirrors sync it up.
The CR Wiki page (1) currently states:
"At present 22 September 2011 and later, it is appropriate proper to remove those packages thus: rpm -e --allmatches centos-release-cr and probably also wise, to prevent unwanted error noise, as the content in the file path referred to, has been retired and removed, as superseded by the point release update. "
Sounds like a more appropriate statement might be something like:
"The centos-release-cr package can safely be left in place for future use, and is now in the [extras] repository for ease of access. While the [cr] repository is empty it will effectively be ignored."
Phil
(1) http://wiki.centos.org/AdditionalResources/Repositories/CR
On 09/23/2011 09:52 PM, Phil Schaffner wrote:
"The centos-release-cr package can safely be left in place for future use, and is now in the [extras] repository for ease of access. While the [cr] repository is empty it will effectively be ignored."
the way to install the package should be changed as well
- KB
On 09/23/2011 04:05 PM, Karanbir Singh wrote:
On 09/23/2011 09:52 PM, Phil Schaffner wrote:
"The centos-release-cr package can safely be left in place for future use, and is now in the [extras] repository for ease of access. While the [cr] repository is empty it will effectively be ignored."
the way to install the package should be changed as well
See if it looks OK now:
On 09/23/2011 10:25 PM, Johnny Hughes wrote:
On 09/22/2011 08:16 PM, Ben Galliart wrote:
On 09/17/2011, Karanbir Singh wrote:
Now back to the question on hand, centos-release-cr in 5.7..
Perhaps the best place for the centos-release-cr is in the updates/ repo, rather than the /cr/ repo, since that way it would further reduce the barrier for people to opt-in, a simple 'yum install centos-releae-cr' would get them on the track, and keep them there till such time as they want to opt-out.
Is there any ETA as to when this could be done or at least decided on?
There is no need to upgrade anything. If you installed the package, you are on CR ... then and now.
The CentOS-CR repo points to /5/cr/ (which is 5.7 now and was 5.6 when the repo file was released).
It (/cr/) is currently empty because 5.7/os and 5.7/updates contain all the RPMS that are required to update from 5.6 (or any other version of CentOS).
When 5.8 is released, the RPMs that are part of 5.8 will get put into the /5.7/cr/ and allow people who are opted in to get the updates before the 5.8 release.
I think maybe putting the RPM in "extras", so it is easier to install is doable ... but not a huge issue.
In fact, I have put it there. centos-release-cr is now in extras.
What's the reasoning for putting centos-release-cr in the extras repo ? Imho, the package would fit better in either the updates or cr repositories (with a preference for the later), because these 2 repos allows to get upstream updates and only that, while extras carries a lot of packages not coming from upstream. Providing a repository yum configuration from within said repository is quite usual for other repos and it looks strange to have to use one repo to get the conf for another.
The use case is to kickstart an install with base + updates + cr in order to have a fully updated and updatable system with only packages from upstream. Adding extras to the mix to be able to pull just the centos-release-cr package makes the use of other 3rd party repositories more difficult, as extras and 3rd party repo can and do provide overlapping packages. This is true for epel, I guess this is true for others 3rd party repos. Indeed, this can be worked around, but this adds some complexity.
Regards, Xavier
Време: 09/28/2011 10:31 AM, Xavier Bachelot пише:
On 09/23/2011 10:25 PM, Johnny Hughes wrote:
On 09/22/2011 08:16 PM, Ben Galliart wrote:
On 09/17/2011, Karanbir Singh wrote:
Now back to the question on hand, centos-release-cr in 5.7..
Perhaps the best place for the centos-release-cr is in the updates/ repo, rather than the /cr/ repo, since that way it would further reduce the barrier for people to opt-in, a simple 'yum install centos-releae-cr' would get them on the track, and keep them there till such time as they want to opt-out.
Is there any ETA as to when this could be done or at least decided on?
There is no need to upgrade anything. If you installed the package, you are on CR ... then and now.
The CentOS-CR repo points to /5/cr/ (which is 5.7 now and was 5.6 when the repo file was released).
It (/cr/) is currently empty because 5.7/os and 5.7/updates contain all the RPMS that are required to update from 5.6 (or any other version of CentOS).
When 5.8 is released, the RPMs that are part of 5.8 will get put into the /5.7/cr/ and allow people who are opted in to get the updates before the 5.8 release.
I think maybe putting the RPM in "extras", so it is easier to install is doable ... but not a huge issue.
In fact, I have put it there. centos-release-cr is now in extras.
What's the reasoning for putting centos-release-cr in the extras repo ? Imho, the package would fit better in either the updates or cr repositories (with a preference for the later), because these 2 repos allows to get upstream updates and only that, while extras carries a lot of packages not coming from upstream. Providing a repository yum configuration from within said repository is quite usual for other repos and it looks strange to have to use one repo to get the conf for another.
Base repos must reflect what upstream is publishing. Thus, any extra packages must go elswhere.
On 09/28/2011 10:39 AM, Ljubomir Ljubojevic wrote:
Време: 09/28/2011 10:31 AM, Xavier Bachelot пише:
On 09/23/2011 10:25 PM, Johnny Hughes wrote:
On 09/22/2011 08:16 PM, Ben Galliart wrote:
On 09/17/2011, Karanbir Singh wrote:
Now back to the question on hand, centos-release-cr in 5.7..
Perhaps the best place for the centos-release-cr is in the updates/ repo, rather than the /cr/ repo, since that way it would further reduce the barrier for people to opt-in, a simple 'yum install centos-releae-cr' would get them on the track, and keep them there till such time as they want to opt-out.
Is there any ETA as to when this could be done or at least decided on?
There is no need to upgrade anything. If you installed the package, you are on CR ... then and now.
The CentOS-CR repo points to /5/cr/ (which is 5.7 now and was 5.6 when the repo file was released).
It (/cr/) is currently empty because 5.7/os and 5.7/updates contain all the RPMS that are required to update from 5.6 (or any other version of CentOS).
When 5.8 is released, the RPMs that are part of 5.8 will get put into the /5.7/cr/ and allow people who are opted in to get the updates before the 5.8 release.
I think maybe putting the RPM in "extras", so it is easier to install is doable ... but not a huge issue.
In fact, I have put it there. centos-release-cr is now in extras.
What's the reasoning for putting centos-release-cr in the extras repo ? Imho, the package would fit better in either the updates or cr repositories (with a preference for the later), because these 2 repos allows to get upstream updates and only that, while extras carries a lot of packages not coming from upstream. Providing a repository yum configuration from within said repository is quite usual for other repos and it looks strange to have to use one repo to get the conf for another.
Base repos must reflect what upstream is publishing. Thus, any extra packages must go elswhere.
This package is special, as it provides only yum confs and no binaries or anything else, and is needed to actually get the updates upstream is publishing. To be a bit bold, this is not different than the centos-release package, which is not in extras either. Actually, the cr repo definition could just be added to the centos-release package, possibly disabled by default.
Regards, Xavier
On 09/28/2011 04:09 AM, Xavier Bachelot wrote:
On 09/28/2011 10:39 AM, Ljubomir Ljubojevic wrote:
Време: 09/28/2011 10:31 AM, Xavier Bachelot пише:
On 09/23/2011 10:25 PM, Johnny Hughes wrote:
On 09/22/2011 08:16 PM, Ben Galliart wrote:
On 09/17/2011, Karanbir Singh wrote:
Now back to the question on hand, centos-release-cr in 5.7..
Perhaps the best place for the centos-release-cr is in the updates/ repo, rather than the /cr/ repo, since that way it would further reduce the barrier for people to opt-in, a simple 'yum install centos-releae-cr' would get them on the track, and keep them there till such time as they want to opt-out.
Is there any ETA as to when this could be done or at least decided on?
There is no need to upgrade anything. If you installed the package, you are on CR ... then and now.
The CentOS-CR repo points to /5/cr/ (which is 5.7 now and was 5.6 when the repo file was released).
It (/cr/) is currently empty because 5.7/os and 5.7/updates contain all the RPMS that are required to update from 5.6 (or any other version of CentOS).
When 5.8 is released, the RPMs that are part of 5.8 will get put into the /5.7/cr/ and allow people who are opted in to get the updates before the 5.8 release.
I think maybe putting the RPM in "extras", so it is easier to install is doable ... but not a huge issue.
In fact, I have put it there. centos-release-cr is now in extras.
What's the reasoning for putting centos-release-cr in the extras repo ? Imho, the package would fit better in either the updates or cr repositories (with a preference for the later), because these 2 repos allows to get upstream updates and only that, while extras carries a lot of packages not coming from upstream. Providing a repository yum configuration from within said repository is quite usual for other repos and it looks strange to have to use one repo to get the conf for another.
Base repos must reflect what upstream is publishing. Thus, any extra packages must go elswhere.
This package is special, as it provides only yum confs and no binaries or anything else, and is needed to actually get the updates upstream is publishing. To be a bit bold, this is not different than the centos-release package, which is not in extras either. Actually, the cr repo definition could just be added to the centos-release package, possibly disabled by default.
No, no, no, why do we want to sabotage CR? Why does everyone hate it so much?
If it's going to be in the base release file and disabled by default, now we make it even harder, instead of (easy) "yum install" or (less easy) wget into proper place, now you're saying users are going to need to edit files or use "yum --enablerepo" to get updates.
This is an important repo with security patches that could otherwise be months delayed. This should not be something hidden from users.
I still think it should be opt-out, but I can accept that it is not in the mission to break individual release compatibility with upstream by default. Let's NOT intentionally make it harder to install this, please, please.
On 09/28/2011 11:16 AM, Kevin Stange wrote:
On 09/28/2011 04:09 AM, Xavier Bachelot wrote:
On 09/28/2011 10:39 AM, Ljubomir Ljubojevic wrote:
Време: 09/28/2011 10:31 AM, Xavier Bachelot пише:
On 09/23/2011 10:25 PM, Johnny Hughes wrote:
On 09/22/2011 08:16 PM, Ben Galliart wrote:
On 09/17/2011, Karanbir Singh wrote:
> Now back to the question on hand, centos-release-cr in 5.7..
> Perhaps the best place for the centos-release-cr is in the updates/ > repo, rather than the /cr/ repo, since that way it would further reduce > the barrier for people to opt-in, a simple 'yum install > centos-releae-cr' would get them on the track, and keep them there till > such time as they want to opt-out.
Is there any ETA as to when this could be done or at least decided on?
There is no need to upgrade anything. If you installed the package, you are on CR ... then and now.
The CentOS-CR repo points to /5/cr/ (which is 5.7 now and was 5.6 when the repo file was released).
It (/cr/) is currently empty because 5.7/os and 5.7/updates contain all the RPMS that are required to update from 5.6 (or any other version of CentOS).
When 5.8 is released, the RPMs that are part of 5.8 will get put into the /5.7/cr/ and allow people who are opted in to get the updates before the 5.8 release.
I think maybe putting the RPM in "extras", so it is easier to install is doable ... but not a huge issue.
In fact, I have put it there. centos-release-cr is now in extras.
What's the reasoning for putting centos-release-cr in the extras repo ? Imho, the package would fit better in either the updates or cr repositories (with a preference for the later), because these 2 repos allows to get upstream updates and only that, while extras carries a lot of packages not coming from upstream. Providing a repository yum configuration from within said repository is quite usual for other repos and it looks strange to have to use one repo to get the conf for another.
Base repos must reflect what upstream is publishing. Thus, any extra packages must go elswhere.
This package is special, as it provides only yum confs and no binaries or anything else, and is needed to actually get the updates upstream is publishing. To be a bit bold, this is not different than the centos-release package, which is not in extras either. Actually, the cr repo definition could just be added to the centos-release package, possibly disabled by default.
No, no, no, why do we want to sabotage CR? Why does everyone hate it so much?
If it's going to be in the base release file and disabled by default, now we make it even harder, instead of (easy) "yum install" or (less easy) wget into proper place, now you're saying users are going to need to edit files or use "yum --enablerepo" to get updates.
This is an important repo with security patches that could otherwise be months delayed. This should not be something hidden from users.
I still think it should be opt-out, but I can accept that it is not in the mission to break individual release compatibility with upstream by default. Let's NOT intentionally make it harder to install this, please, please.
I certainly don't want to sabotage cr and I completely agree it is mandatory to close the security updates gap between point releases, and as such, I very much welcome the work done on this.
I think at this point my preference would go to have the cr repo definition in the centos-release package and have it enabled by default, just like the regular updates repo (and actually, I would even say extras should not be enabled by default in order to be even closer to what upstream provides, but this is a different matter). I said the cr could be disabled by default only because some people are of the opinion it should be opt-in rather than opt-out, but that's another point to discuss. What I'd like to be cleared now is how to have the repo definition available, as easily as possible.
Regards, Xavier
On 09/28/2011 04:32 AM, Xavier Bachelot wrote:
On 09/28/2011 11:16 AM, Kevin Stange wrote:
This is an important repo with security patches that could otherwise be months delayed. This should not be something hidden from users.
I certainly don't want to sabotage cr and I completely agree it is mandatory to close the security updates gap between point releases, and as such, I very much welcome the work done on this.
Glad to hear. :)
I think at this point my preference would go to have the cr repo definition in the centos-release package and have it enabled by default, just like the regular updates repo (and actually, I would even say extras should not be enabled by default in order to be even closer to what upstream provides, but this is a different matter). I said the cr could be disabled by default only because some people are of the opinion it should be opt-in rather than opt-out, but that's another point to discuss. What I'd like to be cleared now is how to have the repo definition available, as easily as possible.
I would be very happy with that configuration, so long as it's a single easy command (no thinking, copy and paste) for users to get the CR repo or it's on by default. However, I agree in principle that to stay true to the goals of CentOS it may not be appropriate.
If it's not on by default, it should be an RPM package in a repo enabled by default or a magic "cr enable utility" needs to be on the system by default. If it defaults to on, then it should be in centos-release.
Ideally, anyone who knows they want to stay behind on a previous CentOS release (and accepts that risk) knows how to prevent upgrading and will be able to figure out how to disable the CR as well.
On Wed, Sep 28, 2011 at 5:45 AM, Kevin Stange kevin@steadfast.net wrote:
On 09/28/2011 04:32 AM, Xavier Bachelot wrote: If it's not on by default, it should be an RPM package in a repo enabled by default or a magic "cr enable utility" needs to be on the system by default. If it defaults to on, then it should be in centos-release.
Which is exactly what we have now.
yum install centos-release-cr
Done. And now it's enabled.
Tom Sorensen
On Wed, Sep 28, 2011 at 8:13 AM, Tom Sorensen tsorensen@gmail.com wrote:
Which is exactly what we have now.
yum install centos-release-cr
Done. And now it's enabled.
Assuming you read this mail list daily, and didn't try it during the time the rpm didn't exist there. That should cover maybe 2% of the centos base out there...
On 09/28/2011 03:13 PM, Tom Sorensen wrote:
On Wed, Sep 28, 2011 at 5:45 AM, Kevin Stangekevin@steadfast.net wrote:
On 09/28/2011 04:32 AM, Xavier Bachelot wrote: If it's not on by default, it should be an RPM package in a repo enabled by default or a magic "cr enable utility" needs to be on the system by default. If it defaults to on, then it should be in centos-release.
Which is exactly what we have now.
yum install centos-release-cr
Done. And now it's enabled.
Providing you have the extras repo enabled, which is currently the default but could be discussed in the light of staying as close as possible to upstream and which provides 3rd party packages not coming from upstream and conflicting with others 3rd party repositories. I don't see how enabling a repository providing non-upstream packages helps if you want only the updates from upstream and not anything else.
If using the CR repo is now the preferred way to get _all_ upstream updates, then it should be enabled by default and come from the same rpm that enables the updates repo, that is in the centos-release package.
So to summarize my use case, I want all upstream updates, including the ones from the cr repo, but I don't want the extras repo. Having the rpm providing the cr repo definition in the extras repo doesn't work for me. But indeed, I know ways around this...
Regards, Xavier
On 09/28/2011 03:31 AM, Xavier Bachelot wrote:
On 09/23/2011 10:25 PM, Johnny Hughes wrote:
On 09/22/2011 08:16 PM, Ben Galliart wrote:
On 09/17/2011, Karanbir Singh wrote:
Now back to the question on hand, centos-release-cr in 5.7..
Perhaps the best place for the centos-release-cr is in the updates/ repo, rather than the /cr/ repo, since that way it would further reduce the barrier for people to opt-in, a simple 'yum install centos-releae-cr' would get them on the track, and keep them there till such time as they want to opt-out.
Is there any ETA as to when this could be done or at least decided on?
There is no need to upgrade anything. If you installed the package, you are on CR ... then and now.
The CentOS-CR repo points to /5/cr/ (which is 5.7 now and was 5.6 when the repo file was released).
It (/cr/) is currently empty because 5.7/os and 5.7/updates contain all the RPMS that are required to update from 5.6 (or any other version of CentOS).
When 5.8 is released, the RPMs that are part of 5.8 will get put into the /5.7/cr/ and allow people who are opted in to get the updates before the 5.8 release.
I think maybe putting the RPM in "extras", so it is easier to install is doable ... but not a huge issue.
In fact, I have put it there. centos-release-cr is now in extras.
What's the reasoning for putting centos-release-cr in the extras repo ? Imho, the package would fit better in either the updates or cr repositories (with a preference for the later), because these 2 repos allows to get upstream updates and only that, while extras carries a lot of packages not coming from upstream. Providing a repository yum configuration from within said repository is quite usual for other repos and it looks strange to have to use one repo to get the conf for another.
The use case is to kickstart an install with base + updates + cr in order to have a fully updated and updatable system with only packages from upstream. Adding extras to the mix to be able to pull just the centos-release-cr package makes the use of other 3rd party repositories more difficult, as extras and 3rd party repo can and do provide overlapping packages. This is true for epel, I guess this is true for others 3rd party repos. Indeed, this can be worked around, but this adds some complexity.
It is not in the CR repo, because it's purpose is to enable the CR repo. If you have to manually download it and install it (instead of using yum) to enable the repo, then it kind of defeats the purpose for it to be an RPM in the first place. We could just provide the .repo file and say to put it in /etc/yum.repos.d/
It is not in updates because updates is just that ... updates to the packages already in base. Updates is not the place for "Extra" packages that we need to distribute which are not in the upstream RPMS. That is what extras is for...
Extras, on the other hand, is exactly for this kind of package. It is a package, provided by CentOS, that is not upstream ... and is not replacing a package written by upstream. Extras is also enabled by default, so all that is required is to run:
yum install centos-release-cr
To get it installed and enabled. Once installed, it is enabled and it works from that point on.
My personal opinion is that an RPM is not even necessary for this repo ... and that all we should do is put a repo file in the repository itself and tell people do download it ... but if we are going to have an RPM for it, then that RPM should be hosted in the Extras repository.
On 09/28/2011 11:07 AM, Johnny Hughes wrote:
My personal opinion is that an RPM is not even necessary for this repo ... and that all we should do is put a repo file in the repository itself and tell people do download it ... but if we are going to have an RPM for it, then that RPM should be hosted in the Extras repository.
Why not put the cr repo definition in the centos-release then ? Either enabled or disabled.
Regards, Xavier
On 09/28/2011 04:07 AM, Johnny Hughes wrote:
On 09/28/2011 03:31 AM, Xavier Bachelot wrote:
On 09/23/2011 10:25 PM, Johnny Hughes wrote:
On 09/22/2011 08:16 PM, Ben Galliart wrote:
On 09/17/2011, Karanbir Singh wrote:
Now back to the question on hand, centos-release-cr in 5.7..
Perhaps the best place for the centos-release-cr is in the updates/ repo, rather than the /cr/ repo, since that way it would further reduce the barrier for people to opt-in, a simple 'yum install centos-releae-cr' would get them on the track, and keep them there till such time as they want to opt-out.
Is there any ETA as to when this could be done or at least decided on?
There is no need to upgrade anything. If you installed the package, you are on CR ... then and now.
The CentOS-CR repo points to /5/cr/ (which is 5.7 now and was 5.6 when the repo file was released).
It (/cr/) is currently empty because 5.7/os and 5.7/updates contain all the RPMS that are required to update from 5.6 (or any other version of CentOS).
When 5.8 is released, the RPMs that are part of 5.8 will get put into the /5.7/cr/ and allow people who are opted in to get the updates before the 5.8 release.
I think maybe putting the RPM in "extras", so it is easier to install is doable ... but not a huge issue.
In fact, I have put it there. centos-release-cr is now in extras.
What's the reasoning for putting centos-release-cr in the extras repo ? Imho, the package would fit better in either the updates or cr repositories (with a preference for the later), because these 2 repos allows to get upstream updates and only that, while extras carries a lot of packages not coming from upstream. Providing a repository yum configuration from within said repository is quite usual for other repos and it looks strange to have to use one repo to get the conf for another.
The use case is to kickstart an install with base + updates + cr in order to have a fully updated and updatable system with only packages from upstream. Adding extras to the mix to be able to pull just the centos-release-cr package makes the use of other 3rd party repositories more difficult, as extras and 3rd party repo can and do provide overlapping packages. This is true for epel, I guess this is true for others 3rd party repos. Indeed, this can be worked around, but this adds some complexity.
It is not in the CR repo, because it's purpose is to enable the CR repo. If you have to manually download it and install it (instead of using yum) to enable the repo, then it kind of defeats the purpose for it to be an RPM in the first place. We could just provide the .repo file and say to put it in /etc/yum.repos.d/
It is not in updates because updates is just that ... updates to the packages already in base. Updates is not the place for "Extra" packages that we need to distribute which are not in the upstream RPMS. That is what extras is for...
Extras, on the other hand, is exactly for this kind of package. It is a package, provided by CentOS, that is not upstream ... and is not replacing a package written by upstream. Extras is also enabled by default, so all that is required is to run:
yum install centos-release-cr
To get it installed and enabled. Once installed, it is enabled and it works from that point on.
My personal opinion is that an RPM is not even necessary for this repo ... and that all we should do is put a repo file in the repository itself and tell people do download it ... but if we are going to have an RPM for it, then that RPM should be hosted in the Extras repository.
What is the reason for this mentality? KB specifically and strongly recommended using CR between 5.6 and 5.7 because that entire time users are without kernel and other security updates, some of which may be exploitable easily. Yet you suggest that rather than making it simple to add the CR repo to an existing installation with a single "yum" command and easily include the repo into a kickstart without having write a post-install script, to make sure that users must do all the work of a) discovering that CR exists in the first place and b) manually downloading a file and then putting it in the correct place.
I think CR is extremely important unless CentOS will make a commitment to turn around all new upstream releases within 2 weeks, which recently has not happened. CR needs to be widely publicized, easy to install, and easy to opt-in early and permanently to avoid leaving so many unpatched servers in the wild.
-
Ben Galliart -
Gianluca Cecchi -
Johnny Hughes -
Johnny Hughes -
Karanbir Singh -
Kevin Stange -
Leon Fauster -
Les Mikesell -
Ljubomir Ljubojevic -
Manuel Wolfshant -
Marcus Moeller -
Phil Schaffner -
Tom Sorensen -
Xavier Bachelot