[Yum] feature request for using yum a back end?

Robert G. Brown rgb at phy.duke.edu
Wed Nov 12 00:00:57 UTC 2003

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. 


contains a "repository" prewritten to literally plug into /etc/yum.conf,

name=Fedora Project Stable RPMS for RHL 9

(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.


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