FAQ
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

Search Discussions

  • Marcus Moeller at Sep 15, 2011 at 5:34 am

    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
  • Gianluca Cecchi at Sep 15, 2011 at 5:35 am

    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
  • Leon Fauster at Sep 15, 2011 at 6:08 am

    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.
  • Manuel Wolfshant at Sep 15, 2011 at 6:18 am

    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.
  • Xavier Bachelot at Sep 15, 2011 at 6:34 am

    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
  • Manuel Wolfshant at Sep 15, 2011 at 6:51 am

    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)
  • Gianluca Cecchi at Sep 15, 2011 at 7:06 am

    On Thu, Sep 15, 2011 at 12:51 PM, Manuel Wolfshant 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
  • Xavier Bachelot at Sep 15, 2011 at 9:18 am

    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
  • Ben Galliart at Sep 15, 2011 at 8:54 pm

    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.
  • Karanbir Singh at Sep 17, 2011 at 2:23 pm
    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 :)
  • Les Mikesell at Sep 17, 2011 at 3:29 pm

    On Sep 17, 2011 11:24 AM, "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]
    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?
    --
    Les Mikesell
    lesmikesell at gmail.com
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20110917/42a59c1c/attachment.html
  • Ben Galliart at Sep 17, 2011 at 4:24 pm

    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).
  • Kevin Stange at Sep 18, 2011 at 8:53 pm

    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.

    --
    Kevin Stange
    Chief Technology Officer
    Steadfast Networks
    http://steadfast.net
    Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110918/106b8874/attachment.bin
  • Ben Galliart at Sep 22, 2011 at 9:16 pm

    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
  • Johnny Hughes at Sep 23, 2011 at 4:25 pm

    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.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110923/a46de2b2/attachment.bin
  • Kevin Stange at Sep 23, 2011 at 4:49 pm

    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.

    --
    Kevin Stange
    Chief Technology Officer
    Steadfast Networks
    http://steadfast.net
    Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110923/22462f40/attachment.bin
  • Phil Schaffner at Sep 23, 2011 at 4:52 pm
    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
  • Karanbir Singh at Sep 23, 2011 at 5:05 pm

    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
  • Johnny Hughes at Sep 24, 2011 at 1:15 pm

    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:

    http://wiki.centos.org/AdditionalResources/Repositories/CR


    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110924/26c0ff34/attachment.bin
  • Xavier Bachelot at Sep 28, 2011 at 4:31 am

    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
  • Ljubomir Ljubojevic at Sep 28, 2011 at 4:39 am

    ?????: 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.

    --

    Ljubomir Ljubojevic
    (Love is in the Air)
    PL Computers
    Serbia, Europe

    Google is the Mother, Google is the Father, and traceroute is your
    trusty Spiderman...
    StarOS, Mikrotik and CentOS/RHEL/Linux consultant
  • Xavier Bachelot at Sep 28, 2011 at 5:09 am

    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
  • Kevin Stange at Sep 28, 2011 at 5:16 am

    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.

    --
    Kevin Stange
    Chief Technology Officer
    Steadfast Networks
    http://steadfast.net

    Phone: 312-602-2689 x203
    Fax: 312-602-2688

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110928/c077cf3e/attachment.bin
  • Xavier Bachelot at Sep 28, 2011 at 5:32 am

    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
  • Kevin Stange at Sep 28, 2011 at 5:45 am

    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.

    --
    Kevin Stange
    Chief Technology Officer
    Steadfast Networks
    http://steadfast.net

    Phone: 312-602-2689 x203
    Fax: 312-602-2688

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110928/f0131680/attachment.bin
  • Tom Sorensen at Sep 28, 2011 at 9:13 am

    On Wed, Sep 28, 2011 at 5:45 AM, Kevin Stange 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
  • Les Mikesell at Sep 28, 2011 at 9:46 am

    On Wed, Sep 28, 2011 at 8:13 AM, Tom Sorensen 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...

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Xavier Bachelot at Sep 28, 2011 at 11:18 am

    On 09/28/2011 03:13 PM, Tom Sorensen wrote:
    On Wed, Sep 28, 2011 at 5:45 AM, Kevin Stangewrote:
    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
  • Johnny Hughes at Sep 28, 2011 at 5:07 am

    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.


    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110928/a28f938a/attachment.bin
  • Xavier Bachelot at Sep 28, 2011 at 5:12 am

    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
  • Kevin Stange at Sep 28, 2011 at 5:13 am

    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.

    --
    Kevin Stange
    Chief Technology Officer
    Steadfast Networks
    http://steadfast.net

    Phone: 312-602-2689 x203
    Fax: 312-602-2688

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110928/55ee1eab/attachment.bin

Related Discussions

People

Translate

site design / logo © 2022 Grokbase