[Yum] YFRQ ...

Robert G. Brown rgb at phy.duke.edu
Wed Jan 21 17:18:53 UTC 2004

On Wed, 21 Jan 2004, C.Lee Taylor wrote:

> Greetings ...
>     First, great system ... thanks to Seth and all the others that help ...
>     This just another "Yet Another Feature ReQuest" ... I wonder how 
> much time and trouble it would be to be able to amend how yum does 
> installs of request rpms?  Well, again, I am some poor shmuck who does 
> not have the fast internet connection.  So doing and install of rpms now 
> going along the lines of "yum install xxxx", which then goes through the 
> do you want install xxx and all xxx depends on ... I know that there is 
> a command line options to enable to just do it ... but where my problem 
> is, that once yum starts doing it's work, you should wait until it is 
> done before doing another yum install ... Now, it would be great if we 
> could almost queue the installations ... like "yum queue install xxx" 
> and yum would either do it later or start now, but you could add to the 
> queue while it was working, so that it would do it the next run ...

There are two generic solutions to this that I can think of offhand that
don't require extensions (my home setup is on DSL, fast but not THAT
fast and with access/permissions barriers between me and Duke as well).

  a) rsync a copy of your primary repository(s) at home.  Do this once
(it will take days, sure) then run rsync nightly via cron and it will
grab only what it needs.  Properly redirected, yum then will run locally
and very fast indeed.  You'll also reduce your demands on the server
you're using now, overall, and can do things when the phone is in use.
Like a full reinstall, for example, or installing any package you like.

Remember, disk is cheap.  So cheap that you likely have ROOM for a half
dozen full repository mirrors in spare change lying around, if the
system was purchased in the last year or two, cheap enough that maybe
$80 will buy you 80 GB or more if you don't have enough already.  A
full mirror requires only 2-5 GB at absolute most (the biggest hassle
will indeed be the days of rsync'ing -- best run at night or when you're
not home until the initial copy is done...).

  b) write a trivial wrapper script to do what you want, in perl or
python or even /bin/sh.  For example, parse the command line, write the
list of queued installs out to /var/tmp/yum_queue.dat (ideally
appending/inserting it in either xml or a set of lines like:

#  (yum commands)
yum -y install festival
yum update jpilot

Write one script to lock the file and add a line at the end, something

yum_queue "yum -y install libxml2"

Write another script, e.g. "run_yum_queue" that you background "forever"
as a daemon to fork a thread that locks the file, reads and removes the
top line, writes the file back, unlocks it, and executes the requested
yum command with the given arguments.  Make sure that the queue belongs
to root and isn't readable or writable by anybody else, as you'll likely
just run the lines through to system() (and do whatever error checking
you like).  When the thread returns, fork a new one or (if the queue is
empty) either poll maybe every minute or select the file on the basis of
I/O until it isn't empty again.

perl currently supports threads and using them writing the entire daemon
would take maybe an hour and be kinda fun.  The yum_queue script would
be even shorter, and in fact probably wouldn't even be needed if you
make the run_yum_queue script smart enough to deal with collisions on
additions (really pretty easy to do, I think).  You could probably add

# cat >> /var/tmp/yum_queue.dat
yum -y install festival

and do fine "almost always".  The locks are necessary to avoid the
scenario where you execute the cat into the file at the same time the
daemon is reading the file, then the daemon removes the line and
rewrites it (so it is now different than the file you're catting into)
and then you press ^D and write the file back WITH the line that the
daemon removed still there, or worse.  The daemon CAN resolve all this
with enough passes and intelligence without locks, or there are other
solutions if you are imaginative.

Overall, though, yum needs to stay lean and mean; stuff that is easily
implemented with a script or in other ways should be.  You can always
contribute the script back for others to use if you come up with a
particularly lovely solution.


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