I'm not sure if I have the capacity to explain where I see the problems with this. It boils down to a problem with the way modern packaging systems work. I firmly believe that this is not something that could be reasonably accomplished within the frame work of RPM. I can't speak as confidently about other packaging systems, but I've not seen one yet that does a downgrade well. In order to make something like this work, you will need to rethink they way packaging works. The way configuration files are stored, the way dependencies work, the way obsoletes work, etc. RPM packaging, as I see it, is tuned toward very specific tasks, installing software that doesn't exist, and upgrading software that does. Even the latter is more an extension on the former. Yum is a layer too high to solve this problem. Or at least too high of a layer to start. Probably would be more useful to build another tool that would handle that, *after* the packaging mechanism itself was built to deal with that. Do remember that yum relies on RPM to do a bulk of the actual package related functions, yum is just sort of a transport. (A brilliant transport, mind you ;) ). In just the case of configuration files, you run into a problem. Presumably for this, you'd have to have some sort of version control system, that links the file to a given package version. Then you run into a problem with the rest of the package. The way things work currently, we essentially have access to two versions of a package for any given release. The shipping version, and the current errata release. Keeping track of and providing for the distribution of the intermediate packages introduces a big problem. To be safe, you really need to store the package locally, because you won't really be able to rely on your repository to hold onto all version of a package. Or if you can, then you introduce a lot of pain and expense on your package maintainer. Of course, you could just store the diffs locally, so that could help with some of the problems. But then you run into a lot of complicated calculations when doing rollbacks. Even if you are going back to just the previous RPM. I don't even want to get into the insanity of major system components. Thinking about a package that might introduce a moderate chain of dependencies makes my eyes start to bleed. Really though, I think that when considering this problem, the problem of downgrading, we have to look at what we are trying to solve, and what problems the tools we currently have are trying to solve. These tools, rpm and yum, are designed to ease the mass distribution of software. As a sysadmin, my point of view is that the cases where I need to downgrade are going to be more one off, more isolated cases. The effort required to solve this problem is simply not worth it, in my mind. The way I will solve these problems of needing to downgrade is by testing first, removing and re-installing when I have to downgrade, fix the problems with a previous upgraded package and issue another upgrade, or rebuild a system in the case that it is totally screwed. For the places where I'm inclined not to care, like my workstation at home, my laptop, and my beater machine at work (where I do stupid things deliberately), I'm willing to break the system and do weird things to fix problems. For the systems I consider important, I do not trust the current design of RPM packaging to use even another tool to do the downgrade. My summary is that this problem really needs to be solved by a radically different tact. Either by methods involving a lot of people interactions (uninstalling/reinstalling packages, or re-installing systems) or by building a new packaging system designed to allow for downgrading (even if new == a new version of RPM.) There's a *lot* of thinking that needs to be done in that case. --Chris On Sat, 2003-11-22 at 08:31, Robert G. Brown wrote: > 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
