On Wed, 5 Mar 2003, Troy Dawson wrote: > Howdy, > 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 work. 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 while. 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 for them. 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 chore, here. rgb > > Troy > > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum > 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
