> > Based on the above I'd say there's clearly a demand for urpmi.recover , > > and a non-zero quantity of people using it right now. > > I don't disagree at all. I just think that the vast majority of the users > actually just want rollback/recover as in downgrade to previous version > when the latest upgrade broke something, essentially rpm -Uvh > --oldpackage <previous version>. Of course the old package needs > to be somewhere available for you to be able to do that, but instead of > rpm creating packages with busted up contents, you could use the upper > level depsolver to cache all downloads (no more diskspace wasted than with > --repackage) and downgrade at request.
Well until a new package does something heinous or irreversible to a config file. The really do want the original configs put back, they just don't know it. I rememberin the solaris days their was an upgrade to Sendmail that totally zapped your sendmail.cf...course that was going forward, but the idea is the same. People, intuitively expect things to be back they way they were after a rollback, even if they can't define all the details of what that actually means. Or put another way, they expect things to work like they used too...thats a very real requirement, even if it is a tad subjective. But then I can't remember the last time I argued with a customer about their expectations being too subjective. > > I think practically all depsolvers offer the caching option already, any > many if not all support downgrading too. What's missing is version history > information, ie "revert selected/all packages to whatever versions they > had yesterday because todays update broke stuff", rpmdb only stores the > installation date, not version history. The version history, though not kept in a straight forward way that us humans can understand, was retrievable via walking backwards through installtids in the db and removetids in the repackaged packages. If it were me I would have done things completely differently by actually having a straightforward no questions about it transaction history. That said, there is something to be gained by having some of that history in the packages themselves (durability), but still, I would do both, and then use one to audit the other. After I fixed them, Jeff's forward links and backward links you'll find in the later Johnsonian versions of rpm actually do this (i.e. add more durability, but not ease of understanding). Cheers...james _______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint