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

David Farning dfarning at sbcglobal.net
Tue Nov 11 19:00:26 UTC 2003


On Tue, 2003-11-11 at 12:12, Robert G. Brown wrote:
> On Tue, 11 Nov 2003, David Farning wrote:
> 
> > I got yum working as a back end to redhat-config-packages yesterday--see
> > screen shot below.
> 
> Pretty.  I would suggest that you remain open to making "something
> completely different" in the fullness of time.
I agree--so I am treating this iteration as an effort to open some lines
of communication between seth, fedora, and other developers how best to
interact with yum.  I willing to put down money that yum will become the
back end of choice for developers.   

>   For example, a tree view might be more useful than a flat view.

Again agree-- just figured the basic yum-gui interaction could be
established before adding features.   

>   Also, right now yum uses several
> DIFFERENT commands to present information on a given package -- info,
> list, provides -- and hides package dependencies and conflicts from a
> user until they are ready to actually install.  This is fine in a
> command line environment, but a GUI could present a unified view of
> much of this, and in fact could even present a lot of it at the same
> time.
> 
> Just as an example, if you display had separate windows for "info",
> "provides", a tree view of dependencies with all the UNinstalled
> depenencies expanded, then a mouse "hover" over or click on a package
> name could "instantly" display the package info in these windows.  A
> good graphical view of dependencies would actually extend yum's
> capabilities in a meaningful way, in my opinion, especially if one could
> click on unexpanded tree nodes and observe the longer range consequences
> of rearranging packages to accomodate them and visibly see dependency
> loops and the like.

 I am wondering how much junk should be hung on the primary tree.  My experiences
 with synaptic say the tree gets unwieldy quickly.  Once seth and the other get the
 metadata stuff sorted out, I'll cross that bridge.  But, I am leaning towards a click
 event passing namearch back to yum to grab the metadata and display it in a a notebook.  


> I'd also recommend keeping some sort of "review actions" window before
> actually installing or removing anything -- encapsulating yum's
> interactive reluctance to do anything without letting a user tell it
> twice.  This is especially important on a GUI where you might click
> twenty items for installation, some of which have scrolled far off the
> final screen and may have been incorrectly selected.

Also agree-- click events in a session are used to create a transactionSet which will
be passed back to yum after review and approval. 
  

> 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?

> Very cool, though.  Should definitely improve the utility of yum to
> "users" who aren't also unix admin geeks with a high command line
> comfort level.

>   rgb
> 
> > Three considerations that would help me and others who would like to use
> > yum.
> 
> 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. 
 
Thanks
David Farning




More information about the Yum mailing list