> 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. > Rob, The ideas you describe above are: 1. not feasible given the amount of time I have available to devote to yum 2. many of them aren't even implemented at the rpm level 3. far too complex for most people to use effectively. A single package downgrade is possible, however, rollbacks and downgrades suffer from the %scriptlets having to be reversed and have to be written to be handled that way, additionally the handling of config files is almost impossible, if not so error prone as to be considered fatally poor. The idea you're describing is neat, as an idea, but in practical use you're better off backing up /etc and blowing away the rest of / except for your data. This is not a reasonable request and if someone wanted something CLOSE to this implemented it would require, at minimum, a solid 6 months of design and specification in addition to implementation time. So I'd like to make sure it is clear to everyone that I'm not inclined to take on rob's RFE, it's not in the scope of this project, imo, and it's just not a feature that I'd envision being used by 90% or more of the population. -sv
