[Yum] history, tagged installations, and downgrade

[Robert G. Brown]

This is just to add a couple of related feature suggestions for the
future.  Recent discussion has indicated that a "downgrade" feature
would be very useful.  I would go further and say that to optimally
support development efforts in e.g. fedora and elsewhere in our Brave
New World as well as to permit systems to be kept optimally stable, both
version freeze and free upward/downward mobility in version are
highly desireable.  To support these in turn, I'd suggest the
possibility of yum being given a complete CVS-like history mechanism.
In fact, given that yum's philosophy is to work on top of existing
tools, it wouldn't be totally crazy for yum to implement a CVS layer to
manage the history mechanism.  This could be done with a secondary
tool or a simple command line option, on any desired granularity (e.g.
run once a day in the nightly cron).

The way I envision it working is to dump the full package list (fully
expanded, not compressed by groups) into e.g. /var/cache/yum/rpmlist
that is kept under CVS control.  The file is rebuilt whenever yum is
appropriately invoked and automagically overnight, with a CVS commit
that will of course do nothing if nothing has changed (the usual case).
IF yum could then be asked to install specific RPMs by revision number
or better yet to downgrade to specific SETS of RPMs by CVS tag and IF
repositories were managed by simply adding updates and never removing
the old RPMs as they are superceded, one could actually do the
following:

  a) Install RPM A and all its dependencies as part of a basic system
install.  Tag resulting full install as "stable_1" a week or four later
as it turns out to be stable and happy.
  b) Install RPM A' ditto, with all sorts of changes occuring
  c) Discover that a horrible bug in dependency ten of RPM A' breaks RPM
C, which your life relies on functioning perfectly while you didn't
really give a rat's ass about A->A'.
  d) No worries, just yum downgrade stable_1.  Lickety-zip, five minutes
later A' and all its ratsnest of dependency changes is gone, and you
didn't have to rebuild the A source RPM and a dozen others and
artificially boost revision numbers to get there.

Obviously I think that this would be a great boon to development sites
e.g. the Mozilla site.  One reason everybody is fairly cautious about
upgrading is the likelihood of something breaking and the PITA of
backing off if it does.  Yum could utterly and forever remove this as a
PITA and indeed make it easy.  (The ability to lock clients to tagged
full revision sets would incidentally be of great benefit to e.g. banks
and hospitals as well, as they often have to undergo a federally
mandated process of testing and approval to change ANYTHING in their
underlying systems).

   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