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