On Tue, 26 Feb 2008, James Olin Oden wrote:
> 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.
Indeed. The thing here is that if you limit the rollback scope to just
config files, things suddenly become far more manageable. It wouldn't cost
an arm and a leg to (optionally) store the entire config file history
separately, say, in a real SCM or something resembling one.
Imagine being able to diff the config files between this and the previous
(or a year ago) version, or what's currently on the system vs what the
package contained when originally installed. Etc.
I'd guess that quite a few sysadmins would just love that...
- Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
