[svlug] yum extender

Rick Moen rick at linuxmafia.com
Fri Jul 8 11:56:45 PDT 2005

Quoting Bill Hubbard (kwooda at netzero.net):

> ...Yum Extender [...] yumex...

Ah.  Either of these terms is sufficiently searchable to find relevent
information on the Net.


It's a GTK+-based front-end shell for the Yum utility, coded by Tim
Lauridsen in Python using Glade (an IDE), in obvious partial imitation
of Synaptic, a similar shell for the apt-get utility.  Information on
the various package repositories to be used (by yum, with or without 
yumex) gets stored as text files /etc/yum/yum.repos.d/*.repo, and
apparently some other global configuration goes in /etc/yumex.repos.conf .

Configuration of Yum itself, the command-line utility that yumex (if
used) invokes on your behalf, resides in /etc/yum.conf (which includes 
references to the various *.repo files in /etc/yum.conf.d/), and the utility 
records its activity (by default) to /var/log/yum.log .

Here are some notes from browsing, about typical use of Yum:

yum update #Update stored info from the repos.  You can add a "-y" flag
           #if you want to answer "yes" to any questions posed.

yum clean #Clear out the /var/cache/yum package cache.

yum install any-package #Fetch & install the latest version of "any-package",
                        #and any dependencies required.

yum remove any-package #Removes "any-package" plus anything that depends on it.

yum search string #Looks for "string" anywhere in the package metadata,
                  #not just the name (as "list" does).

yum check-update  #See what updates are available

yum info any-package

yum list string  #Faster than "search" if you have a package name or
                 #portion of one.

yum list all | less 

yum list recent

yum list installed | less #List all the packages installed in the system

yum list updates | less #List installed pkgs for which updates are available.

yum groupinstall "groupname" #A software group is something like GNOME
                             #or the X Window System; basically a metapackage.

yum groupupdate "groupname"  #Update from the repos.

yum --enablerepo=reponame [action]  #This is essentially what yumex does,
                                    #behind the scenes (where "action" is 
                                    #one of the sorts of things detailed

yum -C [action] #Use the local cache only, without contacting the repos.

yum --enablerepo <reponame> <command>  #Use the specified repo for this
                                       #command, even if it's commented 
                                       #out in /etc/yum.conf.

I'm pretty sure what Daniel Gimpelevich did is (1) install yumex, (2)
populate /etc/yum.conf and /etc/yum.conf.d/*.repo with information about
useful third-party RPM repositories such as Fedora Extras and Dag, and
(3) fetch available-package information from the repos.


> It opens a window with several buttons down the side - three of which
> say Update, Install and Remove.  Depending on which one you click on,
> normally it displays a list of related packages (to update, install or
> remove, respectively).  But all I see is a blank window in each case.
> Does that help paint a picture?

One possibility:  Yumex may simply be unable to contact the
repositories.  Is this machine currently able to reach the Internet?
(Notice that, unless one runs Yum with "-C", it apparently always 
contacts the repositories.  "-C" forces it to use cached information,
only.)  Type "host www.apple.com".  If you don't get IP address and DNS
alias information back, then the machine is off the Net.

In any event, if the diagnostic information provided by yumex isn't
sufficient to tell you what's going on (look in the bottom pane and the
status line at the bottom of the screen, when you push a button), then 
try dropping down a level:  Carry out an action or two using "yum",
directly, e.g., 

# yum -y update

The "#", in this context, by the way, means carry out this action as the
root user:  Notice that the prompt character changes from "$" to "#"
whenever you do "su -" to become the root user.

Among the advantages of command-line tools -- along with being usually 
less fragile, less dependency-laden, more deterministic in behaviour,
and having better debugging output -- is that you can easily
cut-and-paste the entire session (or relevant portion thereof) into your
posts, to satisfy techies' "Show me" predilictions.  Which brings me to:

> Not sure how I can cut and paste from one machine to another, since I do 
> email from Windows.

If you SSH in from your Windows box to your Linux one (see
http://linuxmafia.com/ssh/ for Windows SSH clients), then you can use
command-line tools like yum in the remote-terminal window, and
copy/paste directly into your Windows mail program.  (This of course
assumes that your Windows and Linux box aren't the same machine,

If for whatever reason that is not practical, then you can log your
entire shell session to disk using the "script" utility, i.e.,
/usr/bin/script, which (when run) opens a subshell and starts immediately
capturing all characters in that subshell to a logfile, default name
"typescript".  Ctrl-D or "exit" kills the subshell and terminates the
logging.  You could then edit down the logfile with a text editor to get
rid of extraneous details, and e-mail, or ftp, or scp, etc. the file to
somewhere from which it can be included in your e-mail.

I also might point out that you're perfectly welcome to bring the
machine to the next CABAL meeting, tomorrow (Saturday) in Menlo Park.
It's often easier to solve these matters in person. 

> P.S. Why does this mailing list default to reply to the individual 
> rather than back to the list? 

On most other mailing lists, I would be permitted to explain the technical
considerations, but VP Bill Ward does not permit it here (as, in his view,
too likely to lead to flamewars), and he considered regrettable even my
related explanation here on May 8 of how to use Mailman 2.1's "Avoid
duplicate copies of messages?" setting as a key component of emulating
one's desired reply semantics.  

So, I'll be glad to explain all that on another mailing list or in private
e-mail, but not here.

(Bill W, I'm honestly not trying to argue:  I'm just trying to account
honestly for not answering Bill H's question.  But you might consider
documenting on SVLUG's list policy Web pages what topics are forbidden, 
as the matter is currently nowhere detailed.)

More information about the svlug mailing list