Why is yum not liked by some?

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



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.  (You do not need to build anything from SRPMS).  You
> > make that accessible from the web and run createrepo on it.

> 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.  That means I need to copy that whole repository
> (of a size you said was such a problem mirroring that you had
> to break it at the point releases) and repeat the copy for every
> state where I might want repeatable updates or I have to track
> every change.  I do realize that both of these options are possible,
> I just don't see why anyone considers them desirable.  Compare it
> to how you get a set of consistent updates from a cvs repository
> where someone has tagged the 'known good' states as the changes
> were added.

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.  When the mirroring of the repo takes so 
long, the result becomes that the repositories on the mirrors could, during 
heavy updates, be in an inconsistent state more often that not.  As the 
percentage of inconsistent states versus consistent states rise, the 
usefullness of the repository falls exponentially.

This seems a good application for differential or 'patch' RPM's and a CVS-like 
RPM repository.  The mirroring requirements alone make, in my mind at least, 
a good case for patch RPM's that take up far less space (and take far less 
time to mirror, and can be mirrored in a transaction so that the repository, 
to the yum enduser, is ALWAYS consistent), and then a CVS-like RPM repository 
that stores the initial import and all patches from that import, and builds 
the desired RPM on the fly.  Really, this problem has been dealt with before 
in the various revision control systems.  To mirror the whole repository, 
something like CVSup that gets a consistent copy could be built.  A portion 
of this infrastructure is available now as yam, but the underlying repository 
is far from ACID compliant (and now we're talking databases).

The mirroring size difference alone might make it worthwhile.  But, it is 
likely to require more CPU; one of those trade-offs: CPU versus disk and 
bandwidth.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu

[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