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-0007.sig>