Les Mikesell <lesmikesell at gmail.com> wrote: > 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 There is a difference between "mirroring" (like between servers, disks, etc...) and "copying" (like on the same, single server ;-). Symlinks (same server/mounts) and hard links (same filesystem) are excellent options for APT/YUM repositories. ;-> > I just don't see why anyone considers them desirable. I have to agree with someone else's post ... simple put (in my own words) ... What is it that you don't understand about the "costs" of configuration management? If there is one place _no_ OS can save on, it's configuration management. _No_ distro can solve the configuration management requirement. But at least with UNIX and UNIX-like systems, especially Linux, it is "piecemeal" and "well packaged" enough that it really makes it much, much easier to deploy. > 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. Who says you can_not_ just use RCS/CVS/Subversions to track changes to your test system's RPM database and feed those into YUM ... HMMMMMM?!?!?! (hint, hint, hint, big-@$$ hint ;-). That's _exactly_ what I do with CVS. I have a "complete" repository. I then check out select packages/updates to a "test" system. When I have the "test" system to my liking something to my liking, I then do a listing of all RPMs on that system into a file. I commit that file of RPM package-ver into CVS with a tag. I then check that file out in another repository location. Then I use that file to create hard links in that new repository with 1 command that I write on the command line -- an ultra-simple for loop: for pkg in `cat rpm.list`; do ln ${YUMMY}/${pkg} .; done Where YUMMY (YUM, MY) = My complete YUM repository Bam! I have an exact configuration ready installs, updates, etc... I don't have to worry about any inconsistencies, I already did an update on a test system and it worked, and that's _exactly_ the packages I'm making available in that "production" YUM repository. > Normally I'll want to mirror the official repository to get > the set for testing. How do I know when you are finished > doing your updates so that I don't get an rpm with a > dependency that you haven't copied in yet? > Or if I'm mirroring some other mirror, how do I know their > full set is consistent? I hit problems like > that using yum directly - what will be different if I make > a snapshot at the wrong time? Don't know, but you _can_ mitigate the risk by maintaining a full repository internally, and linking only select file listings that have been tested/resolved on a test system. > That's the 2nd step. I don't know I'm happy with them > until I've applied them, so this copy has to co-exist with > other copies and have separate versions for x86/x86_64, etc. Separate x86_64 and ix86 is not an issue at all. Now knowing what ix86 packages to use in an x86_64 system is a different story. If I was in charge of the Fedora Project, it would be my #1 priority to get this addressed in Fedora Core because they are making some very poor choices IMHO (largely on browser/multimedia). -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith at ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers)