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@xxxxxxxxxxxx
