[CentOS] Why is yum not liked by some?
dag at wieers.com
Sun Sep 11 13:47:12 UTC 2005
On Sun, 11 Sep 2005, Johnny Hughes wrote:
> On Sun, 2005-09-11 at 14:54 +0200, Dag Wieers wrote:
> > On Sun, 11 Sep 2005, David Johnston wrote:
> > > On Fri, 2005-09-09 at 11:01 -0400, Lamar Owen wrote:
> > > > On Thursday 08 September 2005 15:12, Les Mikesell wrote:
> > > > > On Thu, 2005-09-08 at 13:07, Johnny Hughes wrote:
> > > > > > So, seriously, the best thing would be for you to create a directory
> > > > > > that contains all your RPMS ... you put only the ones that you have
> > > > > > approved in there.
> > > > > OK, but I basically want to include all official updates here but
> > > > > I just want to delay/control rolling them out to make sure there
> > > > > are no surprises.
> > > >
> > > > One of the key reasons that CVS works so well for source is that, once the
> > > > initial import is done, everything is done via diffs and patches. This makes
> > > > the repository smaller, and automatically makes the things CVS does well
> > > > (multiple versions, consistent repository states) done. While a CVS commit
> > > > is in progress, for instance, other users still see the previous state; this
> > > > is not true for a YUM repository.
> > >
> > > Hmm. This sounds like the crux of the problem. If the mirroring
> > > software could be tricked into copying the repodata last, wouldn't this
> > > problem (and this thread) go away?
> > rsync does not allow you to specify an order, however rsync has 2 options.
> > --delay-updates will update the mirror at the end of the sync, which is
> > near atomic (this is functionality that Jeff Pitman wrote when I needed it
> > for my repository) and you have an atomic-script that comes with rsync
> > that hardlinks the tree, makes updates in that new tree and finally
> > atomically puts it all back.
> > Mirrors (that copy data as well as metadata) should start using
> > the --delay-updates option. It requires more diskspace during the sync
> > though.
> More disk space is an understatement :) ... it would several gigabytes
> more space when we roll out a new tree. That might be acceptable to
> most mirrors.
If you mean with new tree 4.1 -> 4.2, then I would expect most to be
hard-linked and therefor not consume much extra diskspace during transit.
Only the amount of what has been updated + the amount of what will be
removed, in the CentOS case nothing is being removed (at least not right
away), so actually no additional diskspace is required during transit.
If you mean with new tree a 5.0, then you're not consuming any additional
diskspace during transit either, since what you're updating is exactly
what will be consumed.
Unless I missed something.
> Another problem is that this requires a version of rsync newer that the
> one in CentOS-3 or CentOS-4. CentOS-3 has rsync-2.5.7-5.3E.src.rpm ...
> CentOS-4 has rsync-2.6.3-1. Neither have a --delay-updates (at least
> not listed in man rsync).
Correct, --delay-updates has been added since 2.6.4.
If you look at the changelog you'll see that there are many benefits to
upgrade to 2.6.6. (Better error-reporting is one of the important changes
making it worthwhile if you use it in production with complex
-- dag wieers, dag at wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
More information about the CentOS