[Yum] graphical yum
Robert G. Brown
rgb at phy.duke.edu
Wed Mar 5 17:04:00 UTC 2003
On Wed, 5 Mar 2003, Troy Dawson wrote:
> First off, I've put the latest daily release into our contrib repository
> so that our users can test it more. We'll let you know if anyone finds
> a bug.
> Just out of curiousity, has anyone done any work on some type of
> graphical interface for yum?
> I'm not saying it really needs one, it works great by text alone, but
> being a person who does alot of graphics, I was just wondering.
This is actually a lovely thing to have, once yum really stabilizes in
its features and API. With glade and perl-gtk is is pretty simple to
whomp up a GUI that fronts almost any command line tool. As of ten
seconds ago, our local version of glade doesn't have a python-gtk
interface (if any such thing even exists) so I don't know that it can be
easily done native in python.
Why would it be lovely to have? Because there is an enormous class of
users that would like to be able to add and delete packages from their
personal desktop workstations, and who are relatively ignorant of how to
do things at the command line. Ex-windows users, for example, get very
poofy if they don't have a mouseful interface to something they want to
do, because doing it from the command line means they have to RTFM and
actuall learn something.
This isn't worth critiquing as a desirable or evil behavior, it just is.
And truly, for various classes of relatively simple task, a GUI can
encapsulate and hide much of the manual, so a user DOESN'T have to read
it. This is how e.g. xmms and related tools work -- one doesn't read a
manual to figure out how to select songs to play, one just clicks on a
selection tool that works about the way you'd expect a selection tool to
There are definitely going to be users for whom a selection tool is the
preferred interface. A gui which called yum list as it initialized,
splitting installed and available into two windows, and let one install
or uninstall by highlighting entries in one list or the other and
clicking a button wouldn't be a horrible thing, ESPECIALLY IF there was
an auxiliary window in which the package description automagically
appeared as the selection was clicked or the mouse hovered over it for a
Such a gui needn't be full featured -- yum's "power features" are mostly
for sysadmins and scripting, and of little use to a user. The basic
list, install, uninstall, though, would be lovely, as would an "update"
button, and perhaps buttons for a few other common user operations, if
anyone can think of any.
Problems that I can think of:
a) root access, of course. I say user, but naturally the user has to
have root privileges to install. Thus there are suid (Evil!), su, and
sudo paths to root to consider. For true user workstations (student
systems in the dorms) you'd likely want the gui to just prompt them for
the root password when they crank it up and then run as root thereafter.
b) It makes it easy for a user to break the hell out of their system.
Not FUNDAMENTALLY any easier than yum itself, but the possibility of
accidentally removing (e.g.) procps because of mouse error.
c) It would have to resolve dependency conflicts in a sane way. The
GUI would have to be able to point out to silly beanie users that
removing glibc is likely to be an unbelievably destructive thing to do
even if they "plan to put back a new one" in a moment.
d) This in turn creates a really interesting question: is it possible
to tag packages as "root" controlled vs "user" controlled, and permit
the gui only to mess with "user" controlled (basically userspace)
applications? Is it further possible to permit access to the user
portion (only) with e.g. sudo? This question really applies to yum as
well as the GUI.
For example, even in a managed LAN environment it is pretty reasonable
to permit users to add and remove certain components to their
workstation. It is just insanely dangerous to let them add or remove
ARBITRARY components. Maybe they just don't use kword and would like to
remove it. Maybe they want xine, but their sysadmin didn't install it
on standard desktops (although it is available to yum in the
installation archives). Or perhaps they want octave, or mathematica, or
any of a hundred packages that just do one thing with little dependency
and are completely optional according to the whim of a user.
IF one could identify all the packages in the archive that are in that
general category, AND identify a way for the workstation owner to be
able to install those packages (only), but never any of the base/root
packages that might break the system, that might be a useful thing.
I'd say that this is a generally low priority, though. It would
definitely increase the amount of metadata associated with each package,
and would require an additional stage of LAN level setup. One
presumably would make back the time this took by being able to tell
users once how to install and remove optional packages on their own
instead of having to process their administrative requests one at a time
The list of restricted/permitted packages would need to be LAN local and
not global, as different LANs might require different tools to be
present (no you can NOT remove KDE in our environment, but you CAN
remove KDE in their environment, you CAN add pvm here, but you can NOT
add it there).
Then there is the root thing and security -- how to permit a general
user to run e.g. yum install pvm (which definitely installs in
root-controlled /usr) without the root password, while NOT allowing them
to hack it so that yum gets pvm from their own private RPM (where "pvm"
is an suid root shell) and NOT allowing them to remove the kernel, libc,
or any other "critical" or protected component. Obviously a bit of a
> Yum mailing list
> Yum at lists.dulug.duke.edu
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