On Thu, 13 Nov 2003, Dave Shield wrote: > > this, like a lot of other things need to be > > added outside of yum, not in the core program. Otherwise the yum command > > ends up being yum [command] packages > > > > where command is one of 80 different options. > > Well - if there are 80 separate yum-tasks, then you're going to end > up with either: > yum [command] packages > or 80 different > yum-command packages > > (or something in between). > There are arguments on both sides - lots of little commands clutters up > the filesystem, a single wrapper with lots of little sub-commands clutters > up the command. Both of them clutter up the user's memory! The thing is, it isn't an issue of 80 different options. If you run the permutations of all options there are WAY more than 80 already. Almost the definition of a powerful tool is one that can do lots of things with many useful variations. The issue is one of hierarchical organization. There are only three or four different yum tasks -- installation/update, information gathering, archive configuration, and cache grooming, in rough terms. Right now two of these tasks are unified in the yum client, and the third is split off in yum-arch, where the basis for this break is almost certainly in the underlying data structures and code base required and not functional hierarchy. I personally think that splitting the hierarchy into at least informational and "action" (install/update/clean) commands would actually simplify things at this point, because they take largely orthogonal options (as in -y, -d, -e, -t, -R are pretty much useless in the mostly interactive informational applications, which also take certain suboptions e.g. "installed|available" that are not used by the installation/update "action" commands). This would also give yum a bit of room for growth on both the action and information end, which is needed. There are several new commands or operations that yum is capable of that have been suggested recently. If they are added, they will EITHER de facto start adding new NON-hierarchically organized commands or they'll need to be inserted consistently into the existing hierarchy (which Seth has opposed on the "80 command" basis:-). yum (by implication yum-action), yum-info, and yum-arch is pretty straightforward, and even splits it one the basis of rootspace and userspace, where yum-action requires root but yum-info can run off of the existing cache with no special privileges. > One advantage of the single wrapper form is that it makes it easier to > get a list of what the various commands are: > > yum help > > (or even "yum wrongcommand") - as well as making it easier to keep > this maintained accurately. > With separate yum-commands, then you'd have to remember whether > to use "yum-help" or "yumhelp" or "yum-list-commands" or what. > (Or break the habit of a lifetime and read the documentation!) yum already does this; yum does help when run with no arguments or wrong arguments because it requires at least one argument, so there is nothing to remember. I find that if I'm not running one of the "common" commands -- yum update, yum install, yum list -- I end up using this feature or just a quick man yum to remind myself of what does what. This IS an advantage of the current hierarchy. The disadvantage is that there are arguably too many first tier functions available under yum (13 of them on the version on my laptop) which has created a sort of "resistance" to adding more, especially more that might create a new hierarchy at that level. In fact, because the different first tier functions take different options and different object lists, yum has stopped BEING as autodocumenting as it needs to be in order to function as meaningful help as opposed to a way of "advertising" what yum can do once you figure out how. I find that I have to use the man page anyway. As far as reading the man (and other) documentation: <minirant status='ignorable' affect=':-)'> Once again this is an issue of "powerful commands". I've just written a 20 page article on how to set up a simple repository and use yum to do various things with it, and that's the SHORT intro -- the longer one is the HOWTO, and it isn't even finished (any day now, though, because in the short intro I actually wrote a section on the yum command proper that will form the basis of the missing section in the HOWTO). Some people will never use yum for anything more than automated updates run from cron that they don't even know are happening. Others will use maybe three of the first tier yum commands -- I find that well over 90% of my command line usage is just yum install package, yum update, yum list argglob (installed or available or both). Only a few, mostly "experts" and sysadmins trying to find particular packages or files with incomplete information, will use all of the yum client commands. And ONLY systems experts will use yum-arch at all -- setting up a repository (even a trivial file:// one) requires a bit of gumption. To go beyond the automated update level, you MUST RTFM. The yum prompt is too terse to tell you how to use even yum list -- you might never realize that it takes file globs, and if you were a Unix/linux command line neophyte you might not realize that you'd have to escape those globs from the shell unless you wanted to get "odd" results (generally a terse and uninformative "no match" return). Even the man page doesn't tell you to beware the latter -- it presupposes that the reader is NOT a neophyte and knows what a glob IS, let alone that it must be escaped. To get to where one can easily set up repositories, the man pages become a bit thin even for experts -- they contain all the required information, but it will take most seasoned administrators one or two experimental passes to figure out exactly how it is all put together (at least it did me, and I've only been doing Unix administration since maybe 1986 and had been USING yup and then yum at the client level for some years when I first tried:-). Experts benefit from "working examples" as much as from the man page docs -- if you provide a simple setup that they can clone and which "works" immediately, they can generally tweak and play with the optional variations the man page documents until they achieve happiness. This will at least partly change when a true GUI is finished. A GUI by its nature is largely feature autodocumenting -- menu options and checkboxes are a form of "shorthand" for a hierarchical man section. They are also in their own way dangerous, as they provide the illusion of full control when all too often their maintainers only support a fraction of the actual configuration options and parametrizations. Old Unix hacks tend to mistrust any GUI that purports to completely run portions of the /etc stuff for that very reason -- you read the man pages or other documentation for fstab, for XF86Config, for so much more and you realize that sooner or later you're going to need to go in there with an editor. Windows suffers tremendously from this very thing -- its GUI administrative interface is horribly clunky and you KNOW that it breaks things and omits feature support and has lousy recoverability if the underlying configuration data file (registry) becomes corrupted, and yet the underlying configuration data is incredibly undocumented. </minirant> rgb -- 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
