> > Russ Herrold suggested that maybe the yum command was getting a bit
> > overloaded with options and maybe it'd be worthwhile to have something
> > else to do misc non-pkg-installing/updating/erase related work.
> >
> > so the name yum-tool came out from somewhere, probably from me, b/c I'm
> > boring.
> >
> >
> > so what things would make sense to go in a yum-tool?
> >
> > I can think of these things:
> > yum-tool depends pkgname/file/something (to do what rgb suggested this
> > morning)
> > yum-tool provides (move the provides functionality over there)
> > yum-tool search
> > yum-tool importkey /path/to/gpgkey
> > yum-tool checkheaders
> > yum-tool checkrpmdb
> >
> > anyway - you get the idea - another command, separate from yum that
> > handles misc things that would just kludge up the main cli.
> >
> > maybe a better name than yum-tool
> >
> > or maybe a couple of command names, yum-find, yum-maint or something
OK, you asked for it. The following is a genuine rgbbot(tm) reply, and
can be skipped by all but the criminally insane. Hmmm, gee, everybody
is leaving but Seth...;-)
No, seriously folks:
There are a couple of issues at play here. At the base is the issue of
how best to deal with increasing application complexity -- as yum
continues to get smarter, it naturally starts to collect whole modules
of related "commands", each with its own, sometimes unique, options.
However, an additional consideration is also how best to deal with
>>developmental<< complexity -- how to leave what we might call the "yum
core" as it is more or less snapshotted in 1.x variants alone and stable
while adding and experimenting with exotic and possibly difficult (and
hence likely to break:-) new commands.
Frankly, I don't think adding a separate yum-tool command as proposed
above would improve the situation wrt application complexity. Indeed,
it might well make it worse. Right now the tool is designed along the
lines of:
yum options command package
(yes, right off the man page:-). It is a totally consistent,
autodocumenting interface to the complete functionality of yum. In
addition to man yum, yum -h "does the right thing" and produces a
synopsis of yum's commands.
If I want to check out yum (or any other unix tool) for new features, I
trust the -h Usage in particular to document/synopsize them. A new
command would typically show up here, its details could then be read in
the man pages and any additional documentation like Seth's future
online/paper book, "RPM Maintenance with Yum", to be published right
after he writes it and finds a publisher;-).
Splitting yum means that one has to install two packages (or at least
two programs in one package). If one wants to check for new commands,
one has to run BOTH yum -h AND yum-tools -h to see what's there. To
learn about what "yum info" vs "yum provides" vs "yum search" vs "yum
list" vs... provide in the way of package information (as all of these
are arguably informational commands and not functional
installation/removal/grooming commands) one has to read several man
pages and maybe even switch back and forth to see where particular lines
are drawn and where the particular information one is looking for is
likely to be returned.
Sure, people can cope, but it won't, actually, be less complex for the
user with this sort of functional split.
The fundamental problem is one of task binning and the INNATE complexity
of the toolset. The latter is "irreducible" -- as features and commands
are added, the tool becomes more powerful, and more complex, period.
The only question is whether any particular task partitioning makes it
simpler for a user to learn to use the tool effectively and manage the
complexity.
Note that as far as that goes, yum is not yet CLOSE to the standard
practice of most of the accepted "major unix tools" in terms of
intrinsic complexity of a single interface. tar --help returns what,
two or three full pages of command synopsis alone? Ditto rpm --help, ls
--help,... if anything yum -h is too terse to be fully useful as a
shorthand synopsis. Of course this begs the qeustion of whether or not
the aforementioned unix commands have gotten so complex under a single
rubric that they are no longer easy to learn, and one CAN point to
examples of complex tool SETS that work and are distributed together:
gzip/gunzip/zcat, for example.
>From the point of view of simplifying things, I'd thus argue that a
single toplevel tool name is an accepted if not a good thing --
irreducible complexity under a single rubric, with a single point of
access on autodocumentation and other information about the tool.
>From the point of view of stabilizing the BASIC tool, it is hard to
argue that "freezing" the primary functional core (which is already
pretty adequate) and splitting off the developmental stuff into an
associated tool wouldn't be useful. Even as a "holding pen" for new
ideas that cannot break the functional core this isn't a bad idea. Even
creating a parallel "beta" that is automatically installed along with
yum in ALL cases (even in the stable branch) so that everybody who uses
yum is automatically updated to the latest beta to use or not as they
wish isn't a bad idea. For cron driven, mission critical stuff use yum,
to participate in development or use a bleeding-edge new feature (and
yes, de facto participate in its development:-) use yum-beta.
Thus
yum
would at this point be more or less frozen in a stable variant,
debugging fixes only. It would be cloned (and the tree split) into
yum-beta
which initially would have precisely the same arguments. New commands
could then be added and developed in yum-beta (ideally in a modular way)
and moved over into yum only after being deemed "stable" in the
development process. This probably wouldn't work perfectly (depending
on drift in the yum core required to support the new commands) but it
would work adequately. So this is one sort of split that MIGHT work for
improving stability while still permitting efficient development.
However, this isn't actually what I'd recommend, or rather, it might be
interesting to try this on top of what I suggest next.
If yum WERE to be split, the only way it can split that WOULD actually
simplify its operational complexity would be to (following the logic of
the gzip/gunzip example above) split yum not on developmental but
logical/functional grounds. If this split were clean and consistent and
roughly divided the operational complexity into two nearly equal pieces,
it COULD actually reduce the application complexity perceived by users,
who might well themselves fall into categories that require them to
really only "learn" one of the two tools at least some of the time.
The split that I can offhand think of that makes sense in this regard is
to separate the part of yum that actually retrieves, installs, upgrades,
removes and manipulates packages at a level that REQUIRES root
privileges and is likely to be fully automated from cron for 95% of its
application from the part of yum that does NOTHING but provide
information about packages and that can be run from userspace.
In the current yum, this would (I believe) split out as:
yum -h
Usage: yum [options] <update | upgrade | install | erase |
clean | importkey (etc)> package[list]
Options:
-c [config file] - specify the config file to use
-e [error level] - set the error logging level
-d [debug level] - set the debugging level
-y answer yes to all questions
-R [time in minutes] - set the max amount of time to randonly
run in.
-C run from cache only - do not update the cache
-h, --help this screen
See also: yum-info -h for informational (userspace) commands.
and
yum-info -h
Usage: yum-info [options] [list | provides | check-update |
depends | search | checkheaders (etc)] package[list]
Default:
provides basic info on packagename (current "info" command)
Options:
-c [config file] - specify the config file to use
-e [error level] - set the error logging level
-d [debug level] - set the debugging level
-y answer yes to all questions
-C run from cache only - do not update the cache
-h, --help this screen
See also: yum -h for operational (rootspace) commands.
This division makes sense. Nothing in the second list (AFAICT) requires
any special privileges, and many of these commands are as likely to be
used or useful to users as they are to rooted humans. Most of them are
also MOST likely to be run interactively. The first list of commands
will almost always be run either by a rooted administrator performing
actual system grooming interactively or (most of the time) out of a
fully automated cron job.
In an environment like Duke, where yum comes with the standard campus
install already set up to automagically do the update thing via cron,
even many "rooted" users (a.k.a. students and faculty with their own
systems and little sysadmin skills or experience:-) will >>never need to
use yum itself<< at the command line, or will learn to use e.g.
"yum-info list" and "yum-info search" very quickly to look for
particularly cool packages and then will learn to use yum install,
period. Which is as it should be. Simple, useful stuff should be easy
and close to the default behavior; complex stuff people EXPECT to have
to work to learn, when they need it.
So (to make the usual infinitely long story short) I'd recommend
splitting off the informational/userspace commands from the rootspace
commands OR not splitting it at all AND considering whether or not to
add a -devel tag to one or both of the new commands to differentiate
stable and unstable/new variants and distribute/update both (current
snapshot of devel) whereever desired. That is, if the yum-devel package
is installed at all, yum will keep it current. If the yum-devel package
is slaved to Seth's Latest Snapshot, yum-devel can get new features and
break all over the damn place but not break a production environment,
while still permitting the administrators of that production environment
(likely on this list:-) to play with, test, and work on the development
version without having to actively grab and install each new snapshot.
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
