Les Mikesell <lesmikesell@xxxxxxxxx> 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@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
