No subject

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