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