[Yum] Future feature request...

[Robert G. Brown]

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 at phy.duke.edu