FAQ
hi guys,

We are still in the early days of CentOS-6, and perhaps a change in
policy at this time might be acceptable. I'd like to propose moving the
CR repo into the mainline repos. So the change I'm proposing is :

- to have a /6/ release that is always updated.

- to have the /6.X/ releases that are contained to within that point release

what this means is that /6/ will point at the most recent release of
6.X/ for the os/ & isos/ repo. The other repos would be local to the /6/
symlink, and will be always updated ( and stay that way ).

there is going to be quite a lot of implications backend / mirror side
that we will need to work out, but its effort + pain as a one off, for
what can be a major improvement in the user experience.

thoughts ?

- KB

Search Discussions

  • Marko Bevc at Nov 1, 2011 at 10:26 am
    Hi.

    I agree. I think there is no added value to this seperate repo. Besides it
    is stalling new releases coming out sooner. +1

    Regards,
    Marko
    On Tue, 1 Nov 2011, Karanbir Singh wrote:

    hi guys,

    We are still in the early days of CentOS-6, and perhaps a change in
    policy at this time might be acceptable. I'd like to propose moving the
    CR repo into the mainline repos. So the change I'm proposing is :

    - to have a /6/ release that is always updated.

    - to have the /6.X/ releases that are contained to within that point release

    what this means is that /6/ will point at the most recent release of
    6.X/ for the os/ & isos/ repo. The other repos would be local to the /6/
    symlink, and will be always updated ( and stay that way ).

    there is going to be quite a lot of implications backend / mirror side
    that we will need to work out, but its effort + pain as a one off, for
    what can be a major improvement in the user experience.

    thoughts ?

    - KB
    _______________________________________________
    CentOS-devel mailing list
    CentOS-devel at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.
  • Ferry Huberts at Nov 1, 2011 at 10:40 am

    On 11/01/2011 03:15 PM, Karanbir Singh wrote:
    hi guys,

    We are still in the early days of CentOS-6, and perhaps a change in
    policy at this time might be acceptable. I'd like to propose moving the
    CR repo into the mainline repos. So the change I'm proposing is :

    - to have a /6/ release that is always updated.
    I would welcome this very much, it makes my mirroring setup much easier
    in that I don't have to update it every time a 6.x release comes out
    (since I'm only interested in mirroring the latest release ofcourse)

    --
    Ferry Huberts
  • Karanbir Singh at Nov 1, 2011 at 10:48 am

    On 11/01/2011 02:40 PM, Ferry Huberts wrote:
    I would welcome this very much, it makes my mirroring setup much easier
    in that I don't have to update it every time a 6.x release comes out
    (since I'm only interested in mirroring the latest release ofcourse)
    It is actually going to add a lot of complexity to the mirroring setup.
    There will no longer be consistent point release tree's, and the /6/
    target will keep changing, all the time. So you will need to carry on
    mirroring the entire centos/6/ tree anyway

    the exact mechanics of how we implement this would still need to be
    worked out.

    - KB
  • Ferry Huberts at Nov 1, 2011 at 10:53 am

    On 11/01/2011 03:48 PM, Karanbir Singh wrote:
    On 11/01/2011 02:40 PM, Ferry Huberts wrote:

    I would welcome this very much, it makes my mirroring setup much easier
    in that I don't have to update it every time a 6.x release comes out
    (since I'm only interested in mirroring the latest release ofcourse)
    It is actually going to add a lot of complexity to the mirroring setup.
    There will no longer be consistent point release tree's, and the /6/
    target will keep changing, all the time. So you will need to carry on
    mirroring the entire centos/6/ tree anyway

    the exact mechanics of how we implement this would still need to be
    worked out.
    ok thanks.

    (my mirror is just a rsync with a local ISP's mirror)


    --
    Ferry Huberts
  • Karanbir Singh at Nov 1, 2011 at 10:55 am

    On 11/01/2011 02:53 PM, Ferry Huberts wrote:
    the exact mechanics of how we implement this would still need to be
    worked out.
    (my mirror is just a rsync with a local ISP's mirror)
    In which case you should be ok to retain the existing targets etc, you
    will just need a bit more space to mirror into, quite a bit more space.

    - KB
  • Digimer at Nov 1, 2011 at 11:47 am

    On 11/01/2011 10:48 AM, Karanbir Singh wrote:
    On 11/01/2011 02:40 PM, Ferry Huberts wrote:

    I would welcome this very much, it makes my mirroring setup much easier
    in that I don't have to update it every time a 6.x release comes out
    (since I'm only interested in mirroring the latest release ofcourse)
    It is actually going to add a lot of complexity to the mirroring setup.
    There will no longer be consistent point release tree's, and the /6/
    target will keep changing, all the time. So you will need to carry on
    mirroring the entire centos/6/ tree anyway

    the exact mechanics of how we implement this would still need to be
    worked out.

    - KB
    Personally, I'd prefer to keep CR separate and have the main releases as
    they've been.

    The idea behind CentOS is that it is super stable and matches upstream.
    I worry that merging CR will hurt the stability. I've enabled CR on some
    test nodes and started seeing issues, minor though they may be.

    So +1 to keeping the status quo. :)

    --
    Digimer
    E-Mail: digimer at alteeve.com
    Freenode handle: digimer
    Papers and Projects: http://alteeve.com
    Node Assassin: http://nodeassassin.org
    "omg my singularity battery is dead again.
    stupid hawking radiation." - epitron
  • Karanbir Singh at Nov 1, 2011 at 11:50 am

    On 11/01/2011 03:47 PM, Digimer wrote:
    Personally, I'd prefer to keep CR separate and have the main releases as
    they've been.
    with the point release going into /6.x/ you will have the option to keep
    things as they are as well. Would that cover your use case ? it would
    allow you to do the point release switch manually, whenever you chose to
    do so.
    The idea behind CentOS is that it is super stable and matches upstream.
    I worry that merging CR will hurt the stability. I've enabled CR on some
    test nodes and started seeing issues, minor though they may be.
    I hope you are opening bug reports for these issues!

    - KB
  • Digimer at Nov 1, 2011 at 11:57 am

    On 11/01/2011 11:50 AM, Karanbir Singh wrote:
    On 11/01/2011 03:47 PM, Digimer wrote:
    Personally, I'd prefer to keep CR separate and have the main releases as
    they've been.
    with the point release going into /6.x/ you will have the option to keep
    things as they are as well. Would that cover your use case ? it would
    allow you to do the point release switch manually, whenever you chose to
    do so.
    So long as I can do a 'yum update' and not get the next y-stream
    packages until the actual y-stream is released proper, I am happy. In
    other words, so long as the stability of my nodes is not effected in any
    way, and compatibility with upstream also remains, I am happy. :)
    The idea behind CentOS is that it is super stable and matches upstream.
    I worry that merging CR will hurt the stability. I've enabled CR on some
    test nodes and started seeing issues, minor though they may be.
    I hope you are opening bug reports for these issues!
    I'm ashamed to say that I neglected to do so. I saw kernel oopses while
    working on other things and didn't get back to them... I'll be sure to
    file a bug next I see it.

    --
    Digimer
    E-Mail: digimer at alteeve.com
    Freenode handle: digimer
    Papers and Projects: http://alteeve.com
    Node Assassin: http://nodeassassin.org
    "omg my singularity battery is dead again.
    stupid hawking radiation." - epitron
  • Les Mikesell at Nov 1, 2011 at 12:19 pm

    On Tue, Nov 1, 2011 at 10:57 AM, Digimer wrote:
    So long as I can do a 'yum update' and not get the next y-stream
    packages until the actual y-stream is released proper,
    But you also don't get potentially critical security updates until the
    full release. That is, yum update won't give you anything.
    I am happy. In
    other words, so long as the stability of my nodes is not effected in any
    way, and compatibility with upstream also remains, I am happy. :)
    What stability problems would you expect from updates beyond a point
    release? The whole point of an 'enterprise' distribution is the
    effort they make to not break api's across a whole major-rev's life.
    Would an upstream system break if you selectively update packages
    beyond a point release without doing a full update?
    I'm ashamed to say that I neglected to do so. I saw kernel oopses while
    working on other things and didn't get back to them... I'll be sure to
    file a bug next I see it.
    That's ummm, strange. Wouldn't you be running that kernel even if the
    whole release had been completed?

    --
    Les Mikesell
    lesmikesell at gmail.com'
  • Digimer at Nov 1, 2011 at 12:37 pm

    On 11/01/2011 12:19 PM, Les Mikesell wrote:
    On Tue, Nov 1, 2011 at 10:57 AM, Digimer wrote:

    So long as I can do a 'yum update' and not get the next y-stream
    packages until the actual y-stream is released proper,
    But you also don't get potentially critical security updates until the
    full release. That is, yum update won't give you anything.
    Having critical updates available in CR gives me the opportunity to,
    when I deem it sufficiently critical, to manually pull the package (and
    it's dependencies) down *or* enabling the CR repo entirely.
    I am happy. In
    other words, so long as the stability of my nodes is not effected in any
    way, and compatibility with upstream also remains, I am happy. :)
    What stability problems would you expect from updates beyond a point
    release? The whole point of an 'enterprise' distribution is the
    effort they make to not break api's across a whole major-rev's life.
    Would an upstream system break if you selectively update packages
    beyond a point release without doing a full update?
    As I mentioned earlier, after enabling CR I started seeing kernel
    oopses. I will need to be more diligent when I see the error next time
    and submit a bug report.
    I'm ashamed to say that I neglected to do so. I saw kernel oopses while
    working on other things and didn't get back to them... I'll be sure to
    file a bug next I see it.
    That's ummm, strange. Wouldn't you be running that kernel even if the
    whole release had been completed?
    I really can't say, as I said, I wasn't sufficiently diligent at the
    time as I was fighting another fire. I do believe the kernel was
    upgraded when I went to the CR repo though. I'll build up another pair
    of machines and see if I can reproduce the issue tomorrow.

    --
    Digimer
    E-Mail: digimer at alteeve.com
    Freenode handle: digimer
    Papers and Projects: http://alteeve.com
    Node Assassin: http://nodeassassin.org
    "omg my singularity battery is dead again.
    stupid hawking radiation." - epitron
  • Lamar Owen at Nov 2, 2011 at 11:38 am

    On Tuesday, November 01, 2011 12:19:31 PM Les Mikesell wrote:
    What stability problems would you expect from updates beyond a point
    release? The whole point of an 'enterprise' distribution is the
    effort they make to not break api's across a whole major-rev's life.
    Would an upstream system break if you selectively update packages
    beyond a point release without doing a full update?
    If the absolute ABI didn't occasionally break from upstream, Scientific Linux would likely not do point releases the way that they do them.
  • Les Mikesell at Nov 2, 2011 at 1:08 pm

    On Wed, Nov 2, 2011 at 10:38 AM, Lamar Owen wrote:
    On Tuesday, November 01, 2011 12:19:31 PM Les Mikesell wrote:
    What stability problems would you expect from updates beyond a point
    release? ?The whole point of an 'enterprise' distribution is the
    effort they make to not break api's across a whole major-rev's life.
    Would an upstream system break if you selectively update packages
    beyond a point release without doing a full update?
    If the absolute ABI didn't occasionally break from upstream, Scientific Linux would likely not do point releases the way that they do them.
    What do you mean? They do point releases so you have the option to
    install something that is not horribly out of date. I thought they
    rolled out updates into the new point release as they built them, not
    waiting for a complete set and install media - and that they had
    always done it that way so there was no expectation of getting updates
    otherwise. That is, they set up the mechanism before anyone could
    know whether point releases would break working 3rd party binaries or
    not. But not having such breakage is the main reason to be running
    RHEL or a clone. If rebuilding from the stock source produces an
    incompatible binary, that is something else.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Greg Lindahl at Nov 18, 2011 at 2:58 pm

    What stability problems would you expect from updates beyond a point
    release? The whole point of an 'enterprise' distribution is the
    effort they make to not break api's across a whole major-rev's life.
    Would an upstream system break if you selectively update packages
    beyond a point release without doing a full update?
    Upstream backports big chunks of kernel code into point releases,
    changing the kernel api/abi. You'll notice this if you have special
    HPC hardware which need updated kernel modules. You'll also notice
    this if you really care about performance. We carefully test
    point-release kernels and only do casual testing of intermediate
    kernels, because the intermediate kernels are the only ones with small
    changes. (Ditto for HPC hardware vendors...)

    Upstream sometimes does big updates of a few user-space rpms in point
    releases, because it has become too hard to backport security fixes.
    Firefix is a common example, and there are others. These sorts of
    changes usually don't happen in an intermediate update.

    Upstream has never tested the combination of packages available in CR.
    It's easily possible that package A depends on package B being updated
    to avoid an obscure bug, but the CR only has A's update. Gentoo users
    are quite familiar with this issue.

    It is likely that many CentOS users think they aren't bothered by
    these issues, but CentOS is used in a lot of production environments,
    and I bet there will be some surprises.

    -- greg

    p.s. Thanks for producing such a good distro!
  • Karanbir Singh at Nov 19, 2011 at 4:23 pm

    On 11/18/2011 07:58 PM, Greg Lindahl wrote:
    Upstream has never tested the combination of packages available in CR.
    if you look at the rhn experience for most people - its actually quite
    in line with the CR/ process - as if it were just one release moving
    along with point-in-time install media being made available. Otoh, its
    been a long time since i did anything with rhn, have things changed ?
    It's easily possible that package A depends on package B being updated
    to avoid an obscure bug, but the CR only has A's update. Gentoo users
    are quite familiar with this issue.
    if CR/ was composed of every and all updates, would that issue be
    reduced to some extent ? completely removed ?

    Also, keep in mind that people can opt out of the process and lock their
    machines into a point release ( eg. lock into 6.1, and only move to 6.2
    when they want to ). So it would still be possible for people to control
    at that level. Its just that rather than this being the default, it
    becomes the opt-in process.
    It is likely that many CentOS users think they aren't bothered by
    these issues, but CentOS is used in a lot of production environments,
    and I bet there will be some surprises.
    Thats the thing we want to reduce.

    - KB
  • Greg Lindahl at Nov 19, 2011 at 11:53 pm

    On Sat, Nov 19, 2011 at 09:23:09PM +0000, Karanbir Singh wrote:
    On 11/18/2011 07:58 PM, Greg Lindahl wrote:
    Upstream has never tested the combination of packages available in CR.
    if you look at the rhn experience for most people - its actually quite
    in line with the CR/ process - as if it were just one release moving
    along with point-in-time install media being made available. Otoh, its
    been a long time since i did anything with rhn, have things changed ?
    Well, my experience (and I think this is fairly typical) is that I
    install all the updates soon after they arrive. So there's no way I
    could end up with a 6.0+6.0updates with a single 6.1 package, which is
    what CR is intended to do.

    During the 5.X series, there was one time that I downgraded a package,
    expat, due to a bug that took Upstream a long time to fix. One.
    Also, keep in mind that people can opt out of the process and lock their
    machines into a point release ( eg. lock into 6.1, and only move to 6.2
    when they want to ).
    Yes, of course, that's what I plan on doing.

    Les Mikesell brings up the reasonable question of whether version
    dependencies might save the day. They probably will in most cases, but
    with both Gentoo and Debian, I have discovered enough errors in those
    dependencies that I don't expect Upstream to get this right,
    especially when almost all of their users aren't going to try to
    install a single 6.1 package on 6.0. I doubt I'll convice Les with
    this argument, but there you have it. As an Enterprise user, I'm not
    interested in experimenting with having most CentOS users do something
    that few Upstream users do. Baaaaah. Baaaaaah (baaaad sheep imitation.)

    -- greg
  • Johnny Hughes at Nov 20, 2011 at 9:38 am

    On 11/19/2011 10:53 PM, Greg Lindahl wrote:
    On Sat, Nov 19, 2011 at 09:23:09PM +0000, Karanbir Singh wrote:
    On 11/18/2011 07:58 PM, Greg Lindahl wrote:
    Upstream has never tested the combination of packages available in CR.
    if you look at the rhn experience for most people - its actually quite
    in line with the CR/ process - as if it were just one release moving
    along with point-in-time install media being made available. Otoh, its
    been a long time since i did anything with rhn, have things changed ?
    Well, my experience (and I think this is fairly typical) is that I
    install all the updates soon after they arrive. So there's no way I
    could end up with a 6.0+6.0updates with a single 6.1 package, which is
    what CR is intended to do.
    Not sure where you got that. CR is intended to add many packages and
    distribute them more evenly throughout the point release creation
    process in a stage way.

    Where the media set is not yet done for the future point release, but
    all the RPMs are in CR.

    It allows us to prioritize building (get enough "dependencies" done and
    get the security updates out in the first batch and release them to CR
    ... then build all the other RPMs in the point release.

    We can also build the updates for the next point release (some of the
    zero day ... also many Firefox, etc. come out) while we are still
    putting together the final point release media set.

    It seems to me that you are arguing for a process that puts out staged
    sets of updates and then saying CR is bad (which is how we can do staged
    updates).
    During the 5.X series, there was one time that I downgraded a package,
    expat, due to a bug that took Upstream a long time to fix. One.
    Also, keep in mind that people can opt out of the process and lock their
    machines into a point release ( eg. lock into 6.1, and only move to 6.2
    when they want to ).
    Yes, of course, that's what I plan on doing.

    Les Mikesell brings up the reasonable question of whether version
    dependencies might save the day. They probably will in most cases, but
    with both Gentoo and Debian, I have discovered enough errors in those
    dependencies that I don't expect Upstream to get this right,
    especially when almost all of their users aren't going to try to
    install a single 6.1 package on 6.0. I doubt I'll convice Les with
    this argument, but there you have it. As an Enterprise user, I'm not
    interested in experimenting with having most CentOS users do something
    that few Upstream users do. Baaaaah. Baaaaaah (baaaad sheep imitation.)
    Again ... not sure what you think CR is.

    CR is basically dumping all updates as we get them built and working
    into a repo that people can install in real time, instead of waiting a
    month (oe more) for every single update to complete before we release
    anything (our current practice). I am really failing to see how that is
    what you are talking about at all ... maybe I am lost.

    -------------- 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/20111120/f7337506/attachment.bin
  • Greg Lindahl at Nov 20, 2011 at 4:32 pm

    On Sun, Nov 20, 2011 at 08:38:18AM -0600, Johnny Hughes wrote:

    Again ... not sure what you think CR is.

    CR is basically dumping all updates as we get them built and working
    into a repo that people can install in real time, instead of waiting a
    month (oe more) for every single update to complete before we release
    anything (our current practice). I am really failing to see how that is
    what you are talking about at all ... maybe I am lost.
    That's exactly what I'm talking about. Sorry that I wasn't clear. Let
    me try again with an example:

    Let's say that "foo" is one of the many packages updated in 6.1.

    With CR, let's say that "foo" happens to be the first 6.1 package
    added to 6.0-CR.

    When I install "foo" from 6.0-CR, I am now running a combination of
    6.0 + a single 6.1 rpm. This combination has probably never been
    tested by upstream; almost all of the upstream people installed almost
    all of the new 6.1 rpms together.

    I'm here posting about this issue because I'm responding to this
    question:
    What stability problems would you expect from updates beyond a point
    release? The whole point of an 'enterprise' distribution is the
    effort they make to not break api's across a whole major-rev's life.
    Would an upstream system break if you selectively update packages
    beyond a point release without doing a full update?
    The fact that upstream hasn't tested these rpm combinations means that
    there's risk involved.

    -- greg
  • Les Mikesell at Nov 20, 2011 at 7:27 pm

    On Sun, Nov 20, 2011 at 3:32 PM, Greg Lindahl wrote:
    I'm here posting about this issue because I'm responding to this
    question:
    What stability problems would you expect from updates beyond a point
    release? ?The whole point of an 'enterprise' distribution is the
    effort they make to not break api's across a whole major-rev's life.
    Would an upstream system break if you selectively update packages
    beyond a point release without doing a full update?
    The fact that upstream hasn't tested these rpm combinations means that
    there's risk involved.
    Updates can't be tested against your local applications either - which
    is what you'd care most about. But the risk of breakage is small
    because upstream doesn't make changes that break API's as a matter of
    policy across major revisions - which is the whole point of
    'enterprise' versions. If you don't change an API, you don't need to
    re-test against everything that uses it.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Greg Lindahl at Nov 20, 2011 at 8:10 pm

    On Sun, Nov 20, 2011 at 06:27:46PM -0600, Les Mikesell wrote:

    The fact that upstream hasn't tested these rpm combinations means that
    there's risk involved.
    Updates can't be tested against your local applications either - which
    is what you'd care most about.
    Well, if you recall what I wrote previously in the thread, I said that
    I tested my local applications carefully against point releases, and
    not that much against intermediate updates, which tend to be much
    smaller and less risky than the changes in the point releases.

    With CR, I'd have to do a lot more testing.
    If you don't change an API, you don't need to
    re-test against everything that uses it.
    You saw my previous comments about how upstream _does_ change APIs,
    but seemingly only in point releases? For example, the InfiniBand
    stuff changed dramatically through the 5.X releases. Each time they'd
    backport a bunch of stuff into the kernel, and release matching
    userspace rpms.

    Sorry to be repeating myself so much, but I think the point about when
    upstream makes bigger changes (point releases) is important for
    everyone to understand.

    -- greg
  • Johnny Hughes at Nov 20, 2011 at 8:42 pm

    On 11/20/2011 03:32 PM, Greg Lindahl wrote:
    On Sun, Nov 20, 2011 at 08:38:18AM -0600, Johnny Hughes wrote:

    Again ... not sure what you think CR is.

    CR is basically dumping all updates as we get them built and working
    into a repo that people can install in real time, instead of waiting a
    month (oe more) for every single update to complete before we release
    anything (our current practice). I am really failing to see how that is
    what you are talking about at all ... maybe I am lost.
    That's exactly what I'm talking about. Sorry that I wasn't clear. Let
    me try again with an example:

    Let's say that "foo" is one of the many packages updated in 6.1.

    With CR, let's say that "foo" happens to be the first 6.1 package
    added to 6.0-CR.

    When I install "foo" from 6.0-CR, I am now running a combination of
    6.0 + a single 6.1 rpm. This combination has probably never been
    tested by upstream; almost all of the upstream people installed almost
    all of the new 6.1 rpms together.
    But, any combination of the released package set should work together
    (within the requires in the RPMs of course).

    People update only a subset of packages all the time, mostly because of
    custom software that they have done themselves.

    But I think I actually agree with one point you are making. I truly
    believe the CR should be exactly as it is now ... optional. If you want
    to use it, you can easily issue the command:

    yum install centos-release-cr

    And if you want to do it only as a released version (no CR), then that
    is OK too and it should be (IMHO) the default.
    I'm here posting about this issue because I'm responding to this
    question:
    What stability problems would you expect from updates beyond a point
    release? The whole point of an 'enterprise' distribution is the
    effort they make to not break api's across a whole major-rev's life.
    Would an upstream system break if you selectively update packages
    beyond a point release without doing a full update?
    The fact that upstream hasn't tested these rpm combinations means that
    there's risk involved.
    You are correct that some ABIs do change ... BUT ... in that case they
    will include that in the RPM by something like "xulrunner > X.Y.Z", then
    you can only install FOO if you meet the requirements. You absolutely
    should be able to install any installable combination that is not hard
    coded with a version in the requirements. If you can't then the RPM
    requirements are not properly programmed and it is a bug.

    -------------- 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/20111120/5c53108d/attachment.bin
  • Tom Sorensen at Nov 21, 2011 at 6:43 pm

    On Sun, Nov 20, 2011 at 4:32 PM, Greg Lindahl wrote:
    When I install "foo" from 6.0-CR, I am now running a combination of
    6.0 + a single 6.1 rpm. This combination has probably never been
    tested by upstream; almost all of the upstream people installed almost
    all of the new 6.1 rpms together.

    I'm here posting about this issue because I'm responding to this
    question:
    What stability problems would you expect from updates beyond a point
    release? ?The whole point of an 'enterprise' distribution is the
    effort they make to not break api's across a whole major-rev's life.
    Would an upstream system break if you selectively update packages
    beyond a point release without doing a full update?
    The fact that upstream hasn't tested these rpm combinations means that
    there's risk involved.
    FSVO risk, sure. Except that upstream recommends this all the time
    when troubleshooting customer systesms.

    We have several systems deployed at customer sites that are RHEL
    5.3... with the 5.6 glibc. And this was recommended by 3rd level
    support, not some 1st level person following a script.

    Sure, I'd prefer to have 5.6 (or 5.7) on the systems, but they're on
    an isolated network scattered all over the globe physically, so doing
    that isn't very easy. And upstream understands this, as well as the
    desire from some customers to not change from a particular sub-version
    without cause. They may not have explicitly tested various package
    combinations, but the commitment to a stable API/ABI means that mixing
    packages from within the same major version number is safe with a
    small number of exceptions (which are in the tech notes).

    IOW, the risk is exceptionally small.

    Tom Sorensen
  • Stephen Walsh at Nov 21, 2011 at 6:50 pm

    On 11/22/2011 10:43 AM, Tom Sorensen wrote:
    FSVO risk, sure. Except that upstream recommends this all the time
    when troubleshooting customer systesms.

    We have several systems deployed at customer sites that are RHEL
    5.3... with the 5.6 glibc. And this was recommended by 3rd level
    support, not some 1st level person following a script.

    Sure, I'd prefer to have 5.6 (or 5.7) on the systems, but they're on
    an isolated network scattered all over the globe physically, so doing
    that isn't very easy. And upstream understands this, as well as the
    desire from some customers to not change from a particular sub-version
    without cause. They may not have explicitly tested various package
    combinations, but the commitment to a stable API/ABI means that mixing
    packages from within the same major version number is safe with a
    small number of exceptions (which are in the tech notes).

    IOW, the risk is exceptionally small.
    With a nice support contract and an army of willing RH engineers on the
    other end of a phone, yes, the risk is small.

    For $Johnny_webhost, who takes his daily income from his business, and
    can't afford the above mentioned support on his rack full of EL boxes
    (which is why he uses centos), he needs to balance the risk of losing
    customers due a security incident vs running a full up to date and
    stable system with a mix of current and upcoming release packages, and
    all with the knowledge in his head and what he can get from the main
    centos list (most of which last time I looked appeared to be a
    conversation about why you should use ubuntu over centos).

    The Lowest Common Denominator is the one we need to think about here.
    The end user that wants EL stability and security, but can't afford to
    spend the money on upstream subscriptions.
  • Les Mikesell at Nov 21, 2011 at 7:05 pm

    On Mon, Nov 21, 2011 at 5:50 PM, Stephen Walsh wrote:
    ?On 11/22/2011 10:43 AM, Tom Sorensen wrote:
    FSVO risk, sure. Except that upstream recommends this all the time
    when troubleshooting customer systesms.
    IOW, the risk is exceptionally small.
    With a nice support contract and an army of willing RH engineers on the
    other end of a phone, yes, the risk is small.
    And you are running the same code...
    For $Johnny_webhost, who takes his daily income from his business, and
    can't afford the above mentioned support on his rack full of EL boxes
    (which is why he uses centos), he needs to balance the risk of losing
    customers due a security incident vs running a full up to date and
    stable system with a mix of current and upcoming release packages, and
    all with the knowledge in his head and what he can get from the main
    centos list (most of which last time I looked appeared to be a
    conversation about why you should use ubuntu over centos).

    The Lowest Common Denominator is the one we need to think about here.
    The end user that wants EL stability and security, but can't afford to
    spend the money on upstream subscriptions.
    The question is whether this person would be better off getting
    security updates that were built post-minor-rev-update or not in a
    default 'yum update'. It's a yes or no question, where recommending
    doing one thing and making the default something else doesn't make a
    lot of sense. With/without the CR approach, the non-security related
    updates are going to come along for the ride, and you will probably
    want them anyway.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Johnny Hughes at Nov 22, 2011 at 3:55 am

    On 11/21/2011 06:05 PM, Les Mikesell wrote:
    On Mon, Nov 21, 2011 at 5:50 PM, Stephen Walsh wrote:
    On 11/22/2011 10:43 AM, Tom Sorensen wrote:
    FSVO risk, sure. Except that upstream recommends this all the time
    when troubleshooting customer systesms.
    IOW, the risk is exceptionally small.
    With a nice support contract and an army of willing RH engineers on the
    other end of a phone, yes, the risk is small.
    And you are running the same code...
    For $Johnny_webhost, who takes his daily income from his business, and
    can't afford the above mentioned support on his rack full of EL boxes
    (which is why he uses centos), he needs to balance the risk of losing
    customers due a security incident vs running a full up to date and
    stable system with a mix of current and upcoming release packages, and
    all with the knowledge in his head and what he can get from the main
    centos list (most of which last time I looked appeared to be a
    conversation about why you should use ubuntu over centos).

    The Lowest Common Denominator is the one we need to think about here.
    The end user that wants EL stability and security, but can't afford to
    spend the money on upstream subscriptions.
    The question is whether this person would be better off getting
    security updates that were built post-minor-rev-update or not in a
    default 'yum update'. It's a yes or no question, where recommending
    doing one thing and making the default something else doesn't make a
    lot of sense. With/without the CR approach, the non-security related
    updates are going to come along for the ride, and you will probably
    want them anyway.
    BUT ... I think that giving the user the choice is certainly preferable.
    We have a process that we use to build and test packages, and when we
    finish we have what we call a stable and completely QA'ed process.

    We offer, at some increased risk (due to less QA), a repo staged updates.

    We made this very easy to get ... just run yum install centos-release-cr
    if you want it.

    But we give the customer the option to take the increase risk or not.

    I think this is the RIGHT way to do this.

    I know that it means if you do not know how to manage your machine (and
    issue a very simple command to get CR) then you don't get it ... but I
    still think that the full repo with full QA should be the default.

    We can recommend that people go ahead and do CR in the release notes,
    but I think it is a mistake to turn it on by default.

    If you would rather add it to the MAIN rpeo file (CentOS-Base.repo) and
    have it off, then require people to edit that to get it, that is fine by
    me too ... but I think a simple command (yum install centos-release-cr)
    is much easier than editing the CentOS-Base.repo file anyway.

    Then, we make people who want CR happy, they can install it and it works
    after install ... and we make the people like Greg happy because he does
    not have to do anything to turn it off if he perceives the risk is too
    great to have it on.

    That way, we can recommend (through the release notes) that people use
    it ... but give them the final option.

    That's my $0.02

    -------------- 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/20111122/2db9387d/attachment.bin
  • David Hrbáč at Nov 22, 2011 at 4:22 am

    Dne 22.11.2011 9:55, Johnny Hughes napsal(a):
    We made this very easy to get ... just run yum install centos-release-cr
    if you want it.

    But we give the customer the option to take the increase risk or not.

    I think this is the RIGHT way to do this.
    Johnny,
    CR repo is fine, glad we have it. I'd like it to stay optional. We are
    using it on boxes not managed by Spacewalk. Boxes managed by Spacewalk
    are not using CR:
    - no erratas (we are using errata binding)
    - packages from CR are going to be moved into Base/Updates repos, but
    Spacewalk server keeps all the downloaded packages

    So, CR is good trade-off, full release would be better.
    Thanks,
    DH
  • Les Mikesell at Nov 22, 2011 at 9:04 am

    On Tue, Nov 22, 2011 at 2:55 AM, Johnny Hughes wrote:

    The question is whether this person would be better off getting
    security updates that were built post-minor-rev-update or not in a
    default 'yum update'. ? It's a yes or no question, where recommending
    doing one thing and making the default something else doesn't make a
    lot of sense. ? With/without the CR approach, the non-security related
    updates are going to come along for the ride, and you will probably
    want them anyway.
    BUT ... I think that giving the user the choice is certainly preferable.
    You have always had the choice of running 'yum update' or not. Or
    running it for specific packages. Or looking at the list it offers
    and making the choice then. That's for people who are paying
    attention. The question is what should happen if you don't pay
    attention and just expect 'yum update' to always install all available
    security updates for the life of the major rev like it always had
    before, dragging along some other bugfixes at minor releases.
    We offer, at some increased risk (due to less QA), a repo staged updates.
    I think the risk factor goes the other way, at least for any machine
    that needs updates at all. We just haven't had a well-known exploit
    to show it yet.
    We made this very easy to get ... just run yum install centos-release-cr
    if you want it.

    But we give the customer the option to take the increase risk or not.
    That would be reduce the risk if any security issues are involved.
    I think this is the RIGHT way to do this.
    Maybe it would have been from the beginning, but at this point I'd bet
    that there are a lot of CentOS installations that haven't updated and
    don't know that they have to do something new and different to get
    security updates.
    I know that it means if you do not know how to manage your machine (and
    issue a very simple command to get CR) then you don't get it ... but I
    still think that the full repo with full QA should be the default.
    How long do you think it is reasonable to go without updates? I'd
    call it mostly a matter of luck if you keep running after any
    combination of a remote exploit plus a local privilege escalation are
    known by anyone - and that has always been just a matter of time.
    Then, we make people who want CR happy, they can install it and it works
    after install ... and we make the people like Greg happy because he does
    not have to do anything to turn it off if he perceives the risk is too
    great to have it on.
    If updating is too much of a risk, don't update at all. He's going to
    get the one he suggested as a problem as soon as you do a real release
    anyway. I don't think he really identified a problem related to having
    the minor rev updates come before a new anaconda/iso is available.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Johnny Hughes at Nov 22, 2011 at 9:29 am

    On 11/22/2011 08:04 AM, Les Mikesell wrote:
    On Tue, Nov 22, 2011 at 2:55 AM, Johnny Hughes wrote:

    The question is whether this person would be better off getting
    security updates that were built post-minor-rev-update or not in a
    default 'yum update'. It's a yes or no question, where recommending
    doing one thing and making the default something else doesn't make a
    lot of sense. With/without the CR approach, the non-security related
    updates are going to come along for the ride, and you will probably
    want them anyway.
    BUT ... I think that giving the user the choice is certainly preferable.
    You have always had the choice of running 'yum update' or not. Or
    running it for specific packages. Or looking at the list it offers
    and making the choice then. That's for people who are paying
    attention. The question is what should happen if you don't pay
    attention and just expect 'yum update' to always install all available
    security updates for the life of the major rev like it always had
    before, dragging along some other bugfixes at minor releases.
    It still does, when we get the release done. We are not going to leave
    the stuff in CR forever. When the release happens, those people get the
    same pacakges as the last version of CR. So they will get the updates too.
    We offer, at some increased risk (due to less QA), a repo staged updates.
    I think the risk factor goes the other way, at least for any machine
    that needs updates at all. We just haven't had a well-known exploit
    to show it yet.
    I don't know what to tell you ... it all comes down to choices. If you
    can't wait to get updates, Buy RHEL. If you don't want RHEL, you decide
    what YOU think is the riskiest situation. if you do nothing, centos
    works exactly like it does now.

    Also, don't forget that we have made MAJOR changes to our build system
    and we are building things much more efficiently now than before.

    We have also found and fixed several issues like these:

    https://bugzilla.redhat.com/show_bug.cgi?idd1739

    https://bugzilla.redhat.com/show_bug.cgi?idt3229

    Which caused us many bad packages.
    We made this very easy to get ... just run yum install centos-release-cr
    if you want it.

    But we give the customer the option to take the increase risk or not.
    That would be reduce the risk if any security issues are involved.
    You have the option to get it if you want it or you can wait. If an
    update breaks your system because of a QA issue and causes you downtime,
    that is also a risk. The issue is, you (the user) get to decide .. not
    Johnny or Les, but the user.
    I think this is the RIGHT way to do this.
    Maybe it would have been from the beginning, but at this point I'd bet
    that there are a lot of CentOS installations that haven't updated and
    don't know that they have to do something new and different to get
    security updates.
    They do not HAVE to do anything new. CR is an option thing that has a
    limited time scope. They will still get updates when we release the
    point release.

    And judge us by the 6.2 release. It should happen soon and we now have
    finalized all our scripting for the new build system for 6.x. Of
    course, new issues will mean we need new scripts, but I think we have it
    working well now.

    We are also expecting several very large build machines from 2 vary
    large sponsors .. I can't name them, but everyone knows them.
    I know that it means if you do not know how to manage your machine (and
    issue a very simple command to get CR) then you don't get it ... but I
    still think that the full repo with full QA should be the default.
    How long do you think it is reasonable to go without updates? I'd
    call it mostly a matter of luck if you keep running after any
    combination of a remote exploit plus a local privilege escalation are
    known by anyone - and that has always been just a matter of time.
    You are in complete control of this ... we get done when we get done.
    If that is not fast enough for you, you must use something else. RHEL
    is available.
    Then, we make people who want CR happy, they can install it and it works
    after install ... and we make the people like Greg happy because he does
    not have to do anything to turn it off if he perceives the risk is too
    great to have it on.
    If updating is too much of a risk, don't update at all. He's going to
    get the one he suggested as a problem as soon as you do a real release
    anyway. I don't think he really identified a problem related to having
    the minor rev updates come before a new anaconda/iso is available.
    Not necessarily. We have FIXED many issues from CR .. also even if they
    are not fixed, they are called out in bugs.centos.org ... like this one:

    http://bugs.centos.org/view.php?idR54

    Easy enough to fix if you are expecting it ... someone in CR found it
    (also upstream).

    The point is ... use CR or don't ... choice is yours. Use CentOS or
    RHEL ... that choice is also yours. If you want SLA level update times,
    you need an SLA level Enterprise Linux.

    -------------- 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/20111122/310eebef/attachment.bin
  • Johnny Hughes at Nov 22, 2011 at 9:39 am
    On 11/22/2011 08:29 AM, Johnny Hughes wrote:

    ....

    Oh, and another thing. We are automating many processes in the QA
    system too...

    https://gitorious.org/+centos-testing

    Everyone can see tests and people who request to can create tests to
    help us check for things that we find are problems.

    This process is getting better for 6.x

    In case you have not noticed, all the updates for c5.x and c4.x have
    been happening within 24 hours (the within a point release updates).

    Things are getting better, not worse.

    -------------- 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/20111122/d120ca02/attachment.bin
  • Gilbert Sebenste at Nov 22, 2011 at 9:43 am

    On Tue, 22 Nov 2011, Johnny Hughes wrote:

    Things are getting better, not worse.
    Noted and appreciated. Thank you, Johnny, and the CentOS team, for
    working hard on this, in spite of upstream making it more
    difficult to do these quickly!

    *******************************************************************************
    Gilbert Sebenste ********
    (My opinions only!) ******
    Staff Meteorologist, Northern Illinois University ****
    E-mail: sebenste at weather.admin.niu.edu ***
    web: http://weather.admin.niu.edu **
    Twitter: http://www.twitter.com/NIU_Weather **
    Facebook: http://www.facebook.com/niu.weather *
    *******************************************************************************
  • Kevin Stange at Nov 22, 2011 at 2:24 pm

    On 11/22/2011 08:04 AM, Les Mikesell wrote:
    On Tue, Nov 22, 2011 at 2:55 AM, Johnny Hughes wrote:

    The question is whether this person would be better off getting
    security updates that were built post-minor-rev-update or not in a
    default 'yum update'. It's a yes or no question, where recommending
    doing one thing and making the default something else doesn't make a
    lot of sense. With/without the CR approach, the non-security related
    updates are going to come along for the ride, and you will probably
    want them anyway.
    BUT ... I think that giving the user the choice is certainly preferable.
    You have always had the choice of running 'yum update' or not. Or
    running it for specific packages. Or looking at the list it offers
    and making the choice then. That's for people who are paying
    attention. The question is what should happen if you don't pay
    attention and just expect 'yum update' to always install all available
    security updates for the life of the major rev like it always had
    before, dragging along some other bugfixes at minor releases.
    I've always thought if you are aware enough that you are selective about
    updates and concerned about breakage of your dependencies (be they ABI,
    API, or otherwise), you'd review the release notes of every package
    before updating anything and stage updates into a testing environment
    before moving them to production, regardless of whether the updates come
    via CR.

    In that case, if the CR is rolled into a mainline continuous
    distribution by default, you'd still be selectively choosing your
    updates based on what they do, rather than blindly installing them and
    assuming they won't break everything.

    If the user is too novice to care or know better, he is going to blindly
    do this either before or after the full QA process. In my experience so
    far with the CR, there have been no significant QA problems with
    packages. Changes upstream that break compatibility will arrive either
    way for most people and not rolling them continuously just delays
    security fixes and the compatibility breakage until an arbitrary future
    time, which really doesn't save anyone any headaches.

    Not only that, but even within a release of EL5, there have been updates
    which had serious operational consequences, such as the openssl
    renegotiation patch, which changed application behavior in occasionally
    incompatible ways.

    All other things equal, I'd always rather err on the side of a system
    service going offline due to a dependency break than exploited due to an
    unpatched security vulnerability.

    --
    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/20111122/1eca75f7/attachment.bin
  • Marko Bevc at Nov 22, 2011 at 3:00 pm
    Well my 5c...nothing beeing wrong with CR repo but does it not upstream
    provider(RH) deploys updates as they come? so if you put them as you
    compile them in the main Repo it would be the same? :) (maybe just chech
    the order...)


    Regards,
    Marko
    On Tue, 22 Nov 2011,
    Les Mikesell wrote:
    On Tue, Nov 22, 2011 at 2:55 AM, Johnny Hughes wrote:

    The question is whether this person would be better off getting
    security updates that were built post-minor-rev-update or not in a
    default 'yum update'. ? It's a yes or no question, where recommending
    doing one thing and making the default something else doesn't make a
    lot of sense. ? With/without the CR approach, the non-security related
    updates are going to come along for the ride, and you will probably
    want them anyway.
    BUT ... I think that giving the user the choice is certainly preferable.
    You have always had the choice of running 'yum update' or not. Or
    running it for specific packages. Or looking at the list it offers
    and making the choice then. That's for people who are paying
    attention. The question is what should happen if you don't pay
    attention and just expect 'yum update' to always install all available
    security updates for the life of the major rev like it always had
    before, dragging along some other bugfixes at minor releases.
    We offer, at some increased risk (due to less QA), a repo staged updates.
    I think the risk factor goes the other way, at least for any machine
    that needs updates at all. We just haven't had a well-known exploit
    to show it yet.
    We made this very easy to get ... just run yum install centos-release-cr
    if you want it.

    But we give the customer the option to take the increase risk or not.
    That would be reduce the risk if any security issues are involved.
    I think this is the RIGHT way to do this.
    Maybe it would have been from the beginning, but at this point I'd bet
    that there are a lot of CentOS installations that haven't updated and
    don't know that they have to do something new and different to get
    security updates.
    I know that it means if you do not know how to manage your machine (and
    issue a very simple command to get CR) then you don't get it ... but I
    still think that the full repo with full QA should be the default.
    How long do you think it is reasonable to go without updates? I'd
    call it mostly a matter of luck if you keep running after any
    combination of a remote exploit plus a local privilege escalation are
    known by anyone - and that has always been just a matter of time.
    Then, we make people who want CR happy, they can install it and it works
    after install ... and we make the people like Greg happy because he does
    not have to do anything to turn it off if he perceives the risk is too
    great to have it on.
    If updating is too much of a risk, don't update at all. He's going to
    get the one he suggested as a problem as soon as you do a real release
    anyway. I don't think he really identified a problem related to having
    the minor rev updates come before a new anaconda/iso is available.
    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.
  • Ljubomir Ljubojevic at Nov 22, 2011 at 3:56 pm

    Vreme: 11/22/2011 09:00 PM, Marko Bevc pi?e:
    Well my 5c...nothing beeing wrong with CR repo but does it not upstream
    provider(RH) deploys updates as they come? so if you put them as you
    compile them in the main Repo it would be the same? :) (maybe just chech
    the order...)
    2c -> 5c Inflation already? ;-)

    You probably haven't read the whole thread. They are discussing possible
    changes in ABI, API... that upstream performs at point releases 5.6,
    5.7, ... compared to Continuous Repo without expected breakage at
    point-release release time.

    You better pedal back 35+ messages and track down particular point of
    discussion before you respond, if you do not understand what I wrote
    just now.


    --

    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
  • Marko Bevc at Nov 22, 2011 at 4:16 pm
    Sorry...must have missed all that mails :D Well as said before it is
    always your choice to run yum update - and that way we can preserve
    original procedure of RH distro ;)

    Regards,
    Marko
    On Tue, 22 Nov 2011, Ljubomir Ljubojevic wrote:

    Vreme: 11/22/2011 09:00 PM, Marko Bevc pi?e:
    Well my 5c...nothing beeing wrong with CR repo but does it not upstream
    provider(RH) deploys updates as they come? so if you put them as you
    compile them in the main Repo it would be the same? :) (maybe just chech
    the order...)
    2c -> 5c Inflation already? ;-)

    You probably haven't read the whole thread. They are discussing possible
    changes in ABI, API... that upstream performs at point releases 5.6,
    5.7, ... compared to Continuous Repo without expected breakage at
    point-release release time.

    You better pedal back 35+ messages and track down particular point of
    discussion before you respond, if you do not understand what I wrote
    just now.

    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.
  • Tom Sorensen at Nov 22, 2011 at 5:27 pm

    On Tue, Nov 22, 2011 at 3:00 PM, Marko Bevc wrote:
    Well my 5c...nothing beeing wrong with CR repo but does it not upstream
    provider(RH) deploys updates as they come?
    No. I don't know where people got this idea that RH delivers that way.

    When 6.2 comes out (any day now) all of the rpms will be made
    available at that time. None of the rpms are pushed into the channel
    prior to that.

    And unless you do some special foo in RHN your systems will pull down
    all of those updates next time you do a "yum update" on them. Or you
    can push them to the system from RHN. That makes it no different from
    what happens when CentOS makes a point release.

    The CR repo is quite different from how RH does it. As I stated
    earlier I don't think that there's any significant danger
    (particularly compared to having no security updates for months, as is
    the current situation with 6) from trickling in RPMs, but it *is*
    different from upstream.

    Tom Sorensen
  • Gianluca Cecchi at Nov 22, 2011 at 5:58 pm

    On Tue, Nov 22, 2011 at 11:27 PM, Tom Sorensen wrote:

    When 6.2 comes out (any day now) all of the rpms will be made
    available at that time. None of the rpms are pushed into the channel
    prior to that.

    And unless you do some special foo in RHN your systems will pull down
    all of those updates next time you do a "yum update" on them. Or you
    can push them to the system from RHN. That makes it no different from
    what happens when CentOS makes a point release.
    Yes,
    but after upstream 6.2 has been released you could also run an update
    command that is not a fully update, but something like

    yum update foo_package

    And this command will pull in what is required by rpm configuration in
    spec file for foo package + its sub-dependencies.
    So, also with upstream, you could be at a certain time, in a mixed 6.1
    + 6.2 level, no guarantee
    And for sure upstream can't test every combination of foo update that
    doesn't imply the whole 6.2 tree changes applied to your system...

    This to say that if CentOS provides an updated package in CR with all
    its dependencies we will get the same effect as we would get in
    upstream.
    If CentOS makes a package foo publicly available but forgets one of
    its dependencies (from an rpm chain point of view) you will get an
    error when you run the yum command.
    (a part from yum/rpm bugs themselves)

    Said that, I vote (if I can) for having CR optional and enabled
    manually by the user as it is now.

    Thanks
    Gianluca
  • Leon Fauster at Nov 23, 2011 at 9:28 am

    Am 22.11.2011 um 23:58 schrieb Gianluca Cecchi:
    On Tue, Nov 22, 2011 at 11:27 PM, Tom Sorensen wrote:

    When 6.2 comes out (any day now) all of the rpms will be made
    available at that time. None of the rpms are pushed into the channel
    prior to that.

    And unless you do some special foo in RHN your systems will pull down
    all of those updates next time you do a "yum update" on them. Or you
    can push them to the system from RHN. That makes it no different from
    what happens when CentOS makes a point release.
    Yes,
    but after upstream 6.2 has been released you could also run an update
    command that is not a fully update, but something like

    yum update foo_package

    And this command will pull in what is required by rpm configuration in
    spec file for foo package + its sub-dependencies.
    So, also with upstream, you could be at a certain time, in a mixed 6.1
    + 6.2 level, no guarantee

    - your scenario would end up in a 6.2 system.

    - the description "mixed" misdescribes the actual process

    - not all rpms will be updated in a point release.

    - a virgin 6.2 installation will install (for sure) a rpm that
    also exists in a virgin 6.1 installation.


    the point is - that this "mixed" combination is a valid one (validated by upstream).


    if the are any dependencies - the "requires/provides" internals of the package system
    will push the necessary packages.

    by the way - CentOS is explicitly taking care of this linking libs and symbols and etceteras



    And for sure upstream can't test every combination of foo update that
    doesn't imply the whole 6.2 tree changes applied to your system...

    This to say that if CentOS provides an updated package in CR with all
    its dependencies we will get the same effect as we would get in
    upstream.
    If CentOS makes a package foo publicly available but forgets one of
    its dependencies (from an rpm chain point of view) you will get an
    error when you run the yum command.
    (a part from yum/rpm bugs themselves)

    Said that, I vote (if I can) for having CR optional and enabled
    manually by the user as it is now.

    me too


    __
    LF
  • Gianluca Cecchi at Nov 23, 2011 at 10:39 am

    On Wed, Nov 23, 2011 at 3:28 PM, Leon Fauster wrote:
    - your scenario would end up in a 6.2 system.

    - the description "mixed" misdescribes the actual process
    the point is - that this "mixed" combination is a valid one (validated by upstream).


    if the are any dependencies - the "requires/provides" internals of the package system
    will push the necessary packages.
    Hi Leon,
    actually I have not understood if you agreed with me or not (a part
    the vote... ;-)
    This is what I mean with "mixed environment" and what I tested
    (considered 5.6 --> 5.7 instead of 6.1 --> 6.2)

    - install base system from rh 5.6 x86_64 dvd iso
    [root at rh56 ~]# uname -r
    2.6.18-238.el5

    [root at rh56 ~]# cat /etc/redhat-release
    Red Hat Enterprise Linux Server release 5.6 (Tikanga)

    - register the server with rhn

    - update some packages
    [root at rh56 ~]# yum update yum
    ...
    Updated:
    yum.noarch 0:3.2.22-37.el5

    Complete!

    [root at rh56 ~]# yum update glibc
    ...
    Updated:
    glibc.i686 0:2.5-65 glibc.x86_64
    0:2.5-65

    Dependency Updated:
    glibc-common.x86_64 0:2.5-65 glibc-devel.i386 0:2.5-65
    glibc-devel.x86_64 0:2.5-65 glibc-headers.x86_64 0:2.5-65
    nscd.x86_64 0:2.5-65

    Complete!

    [root at rh56 ~]# yum update kernel
    ...
    Installed:
    kernel.x86_64 0:2.6.18-274.7.1.el5

    Complete!

    [root at rh56 ~]# yum update redhat-release
    ...
    Updated:
    redhat-release.x86_64 0:5Server-5.7.0.3

    [root at rh56 ~]# cat /etc/redhat-release
    Red Hat Enterprise Linux Server release 5.7 (Tikanga)

    - reboot
    [root at rh56 ~]# uname -r
    2.6.18-274.7.1.el5

    [root at rh56 ~]# rpm -qa|wc -l
    442

    So, after a pure rh e 5.6 install l I then directly updated 10
    packages from rh el 5.7+updates bandwagon...
    While the other 432 packages remained as stock rh el 5.6 original dvd

    This is what I call a mixed environment....
    Note that if I run
    [root at rh56 ~]# yum update
    I'm proposed this:
    ...
    Transaction Summary
    =======================
    Install 1 Package(s)
    Upgrade 140 Package(s)

    Total download size: 116 M
    Is this ok [y/N]: Exiting on user Command
    Complete!

    Is this supported by upstream? I think so.
    And the same process would be with CentOS supposing they provided in
    CR repo the 10 packages above (actually 9, considering redhat-release
    that doesn't carry on any dependencies btw....)

    Hope that this explains better my point about mixed-environment, and
    the final system not being a 5.7 installation...

    Gianluca
  • Leon Fauster at Nov 25, 2011 at 6:39 am
    Hi Gianluca,

    Am 23.11.2011 um 16:39 schrieb Gianluca Cecchi:
    On Wed, Nov 23, 2011 at 3:28 PM, Leon Fauster wrote:
    - your scenario would end up in a 6.2 system.

    - the description "mixed" misdescribes the actual process

    the point is - that this "mixed" combination is a valid one (validated by upstream).

    if the are any dependencies - the "requires/provides" internals of the package system
    will push the necessary packages.
    actually I have not understood if you agreed with me or not (a part
    the vote... ;-) This is what I mean with "mixed environment" and what
    I tested
    (considered 5.6 --> 5.7 instead of 6.1 --> 6.2)

    <snip>...</snip>

    So, after a pure rh e 5.6 install l I then directly updated 10
    packages from rh el 5.7+updates bandwagon...
    While the other 432 packages remained as stock rh el 5.6 original dvd

    This is what I call a mixed environment....

    i agree with you :-)

    To evaluate the implications of the CR repo - like it is or as a
    default repo - i suggest to define some major scenarios. The way
    people use yum update-commands explicitly/manually will be always
    a continuous spectrum (also included: across more then one
    releases e.g. "5.3... with the 5.6 glibc").

    One scenario would be - a system that has CR enabled and therefore
    is in a state that i call e.g "6.(coming release)" minus packages
    that are not already build.

    One such state was mentioned in this thread. A full updated system
    with one (expat) package downgraded. This example had an issue but
    not as result of a continuous update.

    If there are any real issues - i would like to compile them.
    Even the mentioned kernel oops could have there cause elsewhere.

    One good thing to keep in mind - the CR rpms passes through a
    "stable and completely QA'ed process".


    Is this supported by upstream? I think so.

    I would say by design. If a point releases is out (upstream) - the
    CR repo is able to provide a package with ALL necessary rpms that
    resolves the corresponding dependencies.

    Even if kernel-updates of point releases change api's, the dependencies
    of userspace (kernel) packages should reflect necessary requirements.

    And the same process would be with CentOS supposing they provided in
    CR repo the 10 packages above (actually 9, considering redhat-release
    that doesn't carry on any dependencies btw....)
    thats it.

    I understand the mentioned stability hints of some people. I just
    want to show up that a reasonable assessment must include the context.
    We are not speaking about fedora or other quite interesting distros (as
    already mentioned) but about an enterprise distro. This means, it is
    fairly stable over the whole lifecycle (centos way to build the distro included).

    (Example: Even if a major update is done (php 5.1 -> 5.3) the
    "enterprise focus" forces upstream to provide this update as option.

    Hope that this explains better my point about mixed-environment, and
    the final system not being a 5.7 installation...
    Sure - and i didn't explain my point of view correctly.


    The above is more technicaly. The essential question can not be answered here.
    Anyone have to consider there own underlying conditions. Centos can only offer
    the options as needed (e.g. CR as option).


    That's my EUR 0.01


    --
    LF
  • Les Mikesell at Nov 19, 2011 at 4:53 pm

    On Fri, Nov 18, 2011 at 1:58 PM, Greg Lindahl wrote:
    What stability problems would you expect from updates beyond a point
    release? ?The whole point of an 'enterprise' distribution is the
    effort they make to not break api's across a whole major-rev's life.
    Would an upstream system break if you selectively update packages
    beyond a point release without doing a full update?
    Upstream has never tested the combination of packages available in CR.
    It's easily possible that package A depends on package B being updated
    to avoid an obscure bug, but the CR only has A's update. Gentoo users
    are quite familiar with this issue.
    Version dependencies are supposed to be noted in the rpms and this
    isn't gentoo - the apis aren't generally supposed to be changing at
    all or you couldn't expect your own and 3rd party applications to
    continue to run.
    It is likely that many CentOS users think they aren't bothered by
    these issues, but CentOS is used in a lot of production environments,
    and I bet there will be some surprises.
    I've fairly routinely updated individual packages only across minor
    rev changes or held some back without problems. Your argument would
    be more convincing if you had several examples of update combinations
    not prevented by package dependencies that will break something.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Christoph at Nov 1, 2011 at 10:49 am

    hi guys,


    We are still in the early days of CentOS-6, and perhaps a change in
    policy at this time might be acceptable. I'd like to propose moving the
    CR repo into the mainline repos. So the change I'm proposing is :

    - to have a /6/ release that is always updated.

    - to have the /6.X/ releases that are contained to within that point release

    what this means is that /6/ will point at the most recent release of
    6.X/ for the os/& isos/ repo. The other repos would be local to the /6/
    symlink, and will be always updated ( and stay that way ).

    there is going to be quite a lot of implications backend / mirror side
    that we will need to work out, but its effort + pain as a one off, for
    what can be a major improvement in the user experience.

    thoughts ?

    - KB
    Hello

    I agree. The CR-Repo is very much appreciated and - imho - should have a place in the mainline repo.
    This might also take some load off of the mirrors during point release time (as most packages from /os
    are already updated via /cr - for those who use it. Did I get that one right?)
    Changing my mirrorlayout should be no problem.

    +1

    all the best
    Christoph
  • Karanbir Singh at Nov 1, 2011 at 10:56 am
    On 11/01/2011 02:49 PM, christoph wrote
    I agree. The CR-Repo is very much appreciated and - imho - should have a place in the mainline repo.
    This might also take some load off of the mirrors during point release time (as most packages from /os
    are already updated via /cr - for those who use it. Did I get that one right?)
    Changing my mirrorlayout should be no problem.
    that does imply that we get hardlinking right, and people are running
    rsync with -H

    - KB
  • Ljubomir Ljubojevic at Nov 1, 2011 at 10:56 am
    It looks like there is need in little clarification / saying it more clear

    Vreme: 11/01/2011 03:15 PM, Karanbir Singh pi?e:
    hi guys,

    We are still in the early days of CentOS-6, and perhaps a change in
    policy at this time might be acceptable. I'd like to propose moving the
    CR repo into the mainline repos. So the change I'm proposing is :

    - to have a /6/ release that is always updated.
    Does this means CR packages would go into updates repo? I use ISO = os
    repo, + updates repo, for mirroring.
    - to have the /6.X/ releases that are contained to within that point release
    So in 6.1 would go all CR packages and further updates until 6.2 packages?
    what this means is that /6/ will point at the most recent release of
    6.X/ for the os/& isos/ repo. The other repos would be local to the /6/
    symlink, and will be always updated ( and stay that way ).

    there is going to be quite a lot of implications backend / mirror side
    that we will need to work out, but its effort + pain as a one off, for
    what can be a major improvement in the user experience.

    thoughts ?

    - KB
    --

    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
  • Christoph Galuschka at Nov 1, 2011 at 11:04 am

    On 11/01/2011 02:49 PM, christoph wrote
    / I agree. The CR-Repo is very much appreciated and - imho - should have a place in the mainline repo.
    />>/ This might also take some load off of the mirrors during point release time (as most packages from /os
    />>/ are already updated via /cr - for those who use it. Did I get that one right?)
    />>/ Changing my mirrorlayout should be no problem.
    />
    that does imply that we get hardlinking right, and people are running
    rsync with -H

    - KB
    -H is used, thanks to http://wiki.centos.org/HowTos/CreateLocalMirror
    I assume, /cr will be emptied resp. moved to /updates once the point release is done?

    cheers
    Christoph
  • Ljubomir Ljubojevic at Nov 1, 2011 at 11:16 am

    Vreme: 11/01/2011 04:04 PM, Christoph Galuschka pi?e:
    On 11/01/2011 02:49 PM, christoph wrote
    / I agree. The CR-Repo is very much appreciated and - imho - should have a place in the mainline repo.
    />>/ This might also take some load off of the mirrors during point release time (as most packages from /os
    />>/ are already updated via /cr - for those who use it. Did I get that one right?)
    />>/ Changing my mirrorlayout should be no problem.
    />
    that does imply that we get hardlinking right, and people are running
    rsync with -H

    - KB
    -H is used, thanks to http://wiki.centos.org/HowTos/CreateLocalMirror
    I assume, /cr will be emptied resp. moved to /updates once the point release is done?
    Can you please properly reply to posts? I receive them as separate
    threads and it is hard to follow.

    Thanks

    --

    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
  • William Hooper at Nov 1, 2011 at 12:12 pm

    On Tue, Nov 1, 2011 at 10:15 AM, Karanbir Singh wrote:
    what this means is that /6/ will point at the most recent release of
    6.X/ for the os/ & isos/ repo. The other repos would be local to the /6/
    symlink, and will be always updated ( and stay that way ).
    Just so I have it straight:

    - OS won't change from the way it is handled today
    - Updated packages between point releases still go to Updates
    - Packages that are part of the next point release (that are going
    into CR now) will instead go into Updates under the new plan
    - When a point release comes out, OS changes to the new point release
    and Updates gets a cleanup to remove CR and Updates that are part of
    the new point release
    - Cycle repeats

    It seems to me that as long as you are doing any network installs just
    from the OS tree, it shouldn't change from the way it is today. Under
    the new plan, everyone is basically opting in to receive the CR
    updates. I assume the comments about needing more space to mirror is
    because the CR tree basically replaces a large portion of the OS tree?

    --
    William Hooper
  • Kevin Stange at Nov 1, 2011 at 12:58 pm

    On 11/01/2011 09:15 AM, Karanbir Singh wrote:
    hi guys,

    We are still in the early days of CentOS-6, and perhaps a change in
    policy at this time might be acceptable. I'd like to propose moving the
    CR repo into the mainline repos. So the change I'm proposing is :

    - to have a /6/ release that is always updated.

    - to have the /6.X/ releases that are contained to within that point release

    what this means is that /6/ will point at the most recent release of
    6.X/ for the os/ & isos/ repo. The other repos would be local to the /6/
    symlink, and will be always updated ( and stay that way ).

    there is going to be quite a lot of implications backend / mirror side
    that we will need to work out, but its effort + pain as a one off, for
    what can be a major improvement in the user experience.
    I am absolutely in favor of a "continuous release" CentOS 6 that's
    permanent. For a lot of CentOS users, I think there's no real advantage
    to holding back between minor versions and this avoids the need for
    users to knowingly opt-in to retain access to constant security updates.

    We don't really need updated media since our kickstart files always just
    pull in the updates repo (and now CR also). Updated media as a slower
    process in the background is fine with my company.

    As a mirror we certainly have the space to do this. I would hope this
    can be done with hard-linking to reduce the space demands on others
    where space is more of an issue.

    --
    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/20111101/dc87d960/attachment.bin

Related Discussions

People

Translate

site design / logo © 2022 Grokbase