[CentOS-devel] moving the CR repo into mainstream release

Mon Nov 21 01:42:14 UTC 2011
Johnny Hughes <johnny at centos.org>

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