[Yum] yum-tool

Robert G. Brown rgb at phy.duke.edu
Sat May 24 05:15:28 UTC 2003


On 23 May 2003, seth vidal wrote:

> 
> > > Although it's an extreme example, I refer to the man pages for Perl.  
> > > Would anyone really want to make that One Big Man Page?
> > > 
> > 
> > No.  But seperete yum-tool-command programs is opposite of yum's current 
> > mode f operation.  It's contrary to the way things work currently.
> > 
> > I don't understand why we can't have a yum-tool that understands verbs but 
> > also is able to implement verb based the name of the called program (much 
> > liek the way the startup scrtipts are handled, then everybody can have it 
> > their way: There's a yum-tool command, but there can be symlinks back to 
> > yum-tool for each verb it understands and presenst it's self like a 
> > command.
> > 
> 
> This goes farther than I'm comfortable with for fairly specific reasons:
> 1. it's cluttery
> 2. it eats inodes (all those symlinks)
> 3. it makes tab completion hard
> 4. it means the rpm has to keep up with additions to functionality in
> the code

It is also interesting to note at this point (as I screw around with
rebuilding xmms on my laptop under RH 9 so I can play all my various
legacy mp3s, grrr) that rpm appears to have "just" split into rpm and
rpmbuild, presumably for all the reasons being discussed here with
regard to the (far simpler) yum.  popt is used to alias them back into a
single "command" by diehards who prefer to just use rpm and
sort-of-the-old commands form.

Discovering this I got to experience firsthand all the joys of split up
commands.  First one tries rpm --rebuild as usual, it barfs, you RTFM
and learn that they split off the build commands (while, amazingly,
still leaving them just as broken and nonintuitive as they ever were:-).

Even though my fingers still want to type rpm -ba and so forth, RH did
use a logical breakpoint, at least, to split the command, and I imagine
that I will relearn and might one day even find it simpler this way.
However, because they split out and renamed one of the MOST often
scripted variants of rpm, I can now look forward to the true joy of
fixing rpm build targets in a staggering list of my personal makefiles.

Still, that's why god made sed, find, and scripting languages -- to test
our faith and patience fixing fallout from other folks' "good ideas".
It will be especially fun fixing the Makefiles to automagically work on
both new e.g. RH 9 systems and old e.g. RH 7 systems -- a simple "sed -e
"s/rpm -ba/rpmbuild -ba/g" will not work unless I want to break the
makefiles for everybody using older versions of rpm, so I'll have to
figure out a script fragment that determines whether rpmbuild exists and
uses it or falls back to rpm.  Torture.

This kind of worrisome pointless drift that at first glance SOUNDS like
a good idea, but that in actual fact ends up punishing the hell out of
everybody in the known universe that builds rpms with scripts or make
targets is what concerns me.  I think you have to be very careful to
have a very clear rationale and to think about side effects before
splitting something up.

Sure, rpm was overly complex (like tar, perl etc) with arguably "too
much" wrapped into a single command (although of course ALL the
scripting languages are invoked by a single command, not "perl" for one
language command and "perlfun" for another), but rpm has FOUR distinct
operational modes and they only split off ONE, and the one they split
off is the one that will absolutely certainly break every makefile in
existence that has an rpm-building target.  What, are they going to wait
to split off the informational, the installation, and the
"miscellaneous" (db) commands?  Are they going to really spread the
torture out, so those of us who learned long ago how to invoke the
commands in these modes have to RElearn where they are? Sigh.  Lessons
to be learned here, as well.

Now consider yum's single, simple, intuitive interface:

  yum [verb] [modifier] [objectlist]

This is information-theoretically compact and makes sense linguistically
-- there are only a handful of unixoid -letter flags, the verbs are
totally intuitive whole words with synonyms like erase and remove
painlessly recognized.  yum specifies taskset and language you gonna do
something with. verb is what you gonna do.  modifier tells you how you
gonna do it, with a few, rarely needed "flags" (almost NEVER needed
interactively).  objectlist tells you what you gonna do it to.  It
doesn't get any simpler, really.  The same syntax is in common use in
shells and scripting languages and in many unixoid commands for that
very reason.

Altering this, you aren't going to make it less complex -- at best
you're turning it into

  yum-verb1 [modifier] [objectlist]
  yum-verb2 [modifier] [objectlist]

or worse,

  yum-tool1 [verb1 or verb3 or verb4] [m/o]
  yum-tool2 [verb5 verb2 verb6] [m/o]
  ...

(order deliberately scrambled) where you have to BOTH remember the list
of verbs (which is the irreducible and REAL source of both power and
complexity and which define everything that yum can, literally, "do" as
an action) AND where they reside.  C'mon, without looking now, was verb4
in yum-tool1 or yum-tool2?  Is the verb "info" (info me baby:-) in yum,
or would that be in yum-tools, or yum-misc...?  How many scripts already
wrap up yum commands that would have to be rewritten if the verb they
implement happens to move to yum-tools?

I reiterate -- the yum interface is actually amazingly SIMPLE at this
point, and is likely to remain so even if every command thus far
suggested is added.  yum [v/m/o], piece of cake.  Learn the (short!)
list of verbs and you're DONE, for the most part, as the objects are
generally pretty obvious -- a few, rarely needed command flags for the
various verbs, a few fullword modifiers.

If yum >>must<< be split, for God's sake split it in a very deliberate,
functionally grouped way, that won't break many scripts now or later
(the info-user/functional-root split is ideal in this regard as long as
functional-root remains just plain yum, since that is what is likely
cron'd in scripts).  Finally, just split it ONCE, now, and then try to
never have to split it or to have to arbitrarily "decide" where to put
new features ever again.  With a good functional split it should be
obvious which subspace a new command belongs to, and the new name should
be a perfect mnemonic of the split and not "yum-tools".  The whole
command space is a set of "tools", for Pete's sake.  How am I to guess
which particular verb is a "yum tool" vs just a tool in just plain yum?

Still, at least one good thing about a root/user split is that LOTS of
yum users would only have to learn the informational unprivileged verb
(command) set; splitting it would actually make their task easier.  This
could, maybe, balance the otherwise mostly negative aspects of a split.

   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






More information about the Yum mailing list