Why is yum not liked by some?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux