On Tue, 11 Nov 2003, David Farning wrote: > > It would also be useful to encapsulate e.g. the selection of > > repositories from the yum public repo list and other stuff, but I'm sure > > you've got all that planned. > I don't follow you. Could you expand? Visit http://linux.duke.edu/projects/yum/repos/ and you will find a set of links. Each link, e.g. http://linux.duke.edu/projects/yum/repos/fedora-stable-rhl-9 contains a "repository" prewritten to literally plug into /etc/yum.conf, e.g. [fedora-stable-9] name=Fedora Project Stable RPMS for RHL 9 baseurl=http://download.fedora.us/fedora/redhat/9/i386/yum/stable/ (for the indicated example). Could be indented, of course, and yes, it should be XML, but still perfectly functional. This is ONE resource for building a GUI-based yum.conf (which is likely one of the most difficult chores your GUI will do as there is a lot to encapsulate). Other ways might be to actually browse to a repository, enter a repository URL by hand, use an editor and (as Seth suggests) "paste the contents directly into your yum.conf file." However, as a front end you could present the public repo list (each of which SHOULD eventually have a description field indicating where it is, rules, times it is open for public use in the event that an organization only permits it to be used publically during the day but reserves bandwidth for nightly updates for themselves, and so forth). [The advantage of XML here is obvious, as supporting public access windows is something that might make it more acceptable to offer up spare capacity on a repository server that is needed to reliably service its parent organization, but only likely to be loaded by that organization at certain times. An extensible repository tag set would permit such a field (and a comment/description field) to be defined and added without breaking any existing parsers or creating problems with indentation or delimiters.] > > I'm interested in this as well. Now that I've bought a python book and > > learned rudimentary python overnight, the next step is going to be > > figuring out what its internal ABI is. From my experiment writing a yum > > wrapper in perl, invoking yum (or, in all probability, its calls) > > repeatedly to generate its printed output is highly inefficient and > > requires parsing and repacking of the output which is generally a PITA. > > Look at nevral.py that is yum's real strength. You can create nevrals which are > basically smart caches, but creating them is expensive. Once created, Seth has a > bunch of good methods to push and pull stuff from them. > > The other expensive step is the actual testing and installation. > clientStuff.take_action(cmds, nulist, uplist, newlist, obsoleting, > tsInfo, HeaderInfo, rpmDBInfo, obsoleted) > > which only needs to be performed once per session. Yes, it's costly but > the belt and suspenders approach in what gives yum it's durability. Not as costly as invoking yum multiple times to build equally expensive hashes in other shell languages;-) I'll look all this over, and appreciate the hints. 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
