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 like: 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 via: # cat >> /var/tmp/yum_queue.dat yum -y install festival ^D 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. rgb -- 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@xxxxxxxxxxxx
