[Yum] Yum "article"

Robert G. Brown rgb at phy.duke.edu
Wed Nov 19 14:59:56 UTC 2003

On Wed, 19 Nov 2003, Cliff Kent wrote:

>  >> I made the observation in the article because I am aware of at least 
> two people who tried the file:// form by accident ... <<
> You can make that at least three who tried. I did it too.<g>

Did I mention that I was one of them?  No?  Gee, funny how I left that
part out...;-)

Some people have enough experience to persevere and figure it out if it
doesn't work; others (less experienced in the observation that if it
doesn't work, 99% of the time it is your fault and not a bug) might be
tempted to conclude something like "Oh, yum doesn't support
filesystem-based repositories" and quit.  Hence the warning:-)

> Then, I'll be switching to an http:// format pointed at my private web 
> server. I tried a network install of FC1 the other day and will not be 
> going back to CDs. The same file set then makes a [base] for yum.

At home I'm not really sure which way to go.  My repository is on my
home server (with 10 clients I don't really need more than one:-).  It
does NFS and has http up, although really not to much purpose except for
supporting yum and permitting me to test stuff for articles like this.

NFS might actually be more efficient. (I suspect that it is -- depends
on how things like the transport protocol is intertwined with the actual
file access on the server side.  The server has to stat the files and so
forth no matter what, in the case of NFS there is one less level of path
resolution, maybe, and perhaps a more efficient transport layer.)  If I
>>did<< NFS export the repository and simultaneously NFS exported
/var/cache/yum from the server, I could significantly reduce the need to
ever actually transport files.

In fact depending on how yum checks for a file being current, I MIGHT be
able to symlink the RPM directory in the cache back to the RPMs in
repository, so that they are NEVER duplicated and ALWAYS
repository-current.  As I think somebody (Russ?) observed, this MAY
carry a bit of risk with file locking and two hosts trying to grab the
same RPM at the same time.  However, if yum strictly checks the headers
to decide what to do (as I think that it does) it would then still
notice that the revision number had bumped, seek to download the file
but observe before it actually did so that it was already in its cache
(symlinked back to the repository, mind you) and then update it with no
actual transfer taking place.  No transfer also = less trouble with file
locking -- the tiny header files leave a much smaller window for access
overlap.  Of course if one ever entered yum clean, one would trash the
repository unless it were largely RO... hmmm

Probably one of those kids don't try this at home things, at least until
some kid tries it at home and works out all the pain for what may be
pretty much ignorable gain...;-)

> Meanwhile, your explanation is excellent. Too much detail would just 
> confuse most people.

Thanks.  I have a problem with putting in too much detail.  I'm glad
that you don't think that I did.

> This is getting too easy.<g>

That's the hard thing to convey -- yum makes huge blocks of what used to
be true PITA sysadmin chores absolutely trivial.  So trivial that in
lots of cases a system owner does "nothing", and they just happen
(leveraging SOME little effort put in by Seth and Michael and a bit more
effort put in by their local administrator).


Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu

More information about the Yum mailing list