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.
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.centos.org/pipermail/centos/attachments/20050911/0c771ec6/attachment.bin
