yum roll back option?

[n0dalus]

On 1/16/07, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On 1/15/07, n0dalus <n0dalus+redhat at gmail.com> wrote:
> > RPM could provide a mechanism for storing various types of data and
> > macros for common changes (eg changes of file attributes), so that
> > when the install scripts run, any changes they make can be stored
> > somewhere by rpm.
>
> do you account for multiple packages, making changes to the same file?
>  So far I see  assumptions being made about simple one-to-one mapping
> of packages to file changes.
> But if foo and bar both edit a file as part of scriptlet action, what
> happens if you rollback bar but not foo or foo and not bar? Simple
> diffs of file state at package install time are not necessarily
> adequate, unless you can garuntee that scriplets from multiple
> packages do not re-edit files. Can we be so sure of that?
>

If you had read the rest of that paragraph, you would have noticed I
said "...provided they haven't been modified since the install script
ran, which might mean you get .rpmrollback files instead."

In other words, after the install scripts run, they need to save
whatever data (sha1sum, etc) needed so that the rollback script can
check to see if the data has been changed since. If it has been
changed, it can either perform the rollback but make .rpmrollback
files, or just abort.

There is always going to a few packages with complex rpm scripts that
won't ever be rollback safe. I'm sure you could ponder my assumptions
and come up with several rpms that break them, but luckily it doesn't
really matter. The vast majority of packages (look at my numbers in my
previous post) could easily be made safe for rolling back, and a
rollback system would still be useful for rolling back any of these
packages.

As I looked through the rpm scripts, I found they could be split into
a few main categories (ordered more or less by frequency):
1) Updating a cache or index. This is rollback safe, the cache/index
updater just needs to be run after rollback.
2) Installing info pages. It would be nice if these could be installed
without any scripts, as with man pages, but either way it is fairly
easy to rollback.
3) Changing chkconfig stuff and restarting/stopping services
after/before updates/removals. If Fedora ever changes to a new init
system, the former may be possible to do by just installing files into
the right directories. Anyway, this is also rollback safe.
4) Adding users and groups. Rollback safe.
5) Setting up directories and permissions. I have no idea why this is
being done in scripts instead of just in the package. They probably
need to be decided on a case by case basis as to what to do on
rollback (eg, keep the directory, or remove it including any
contents).
6) Other things, long scripts which convert database formats and
things like that. Some of these might not be rollback safe.

n0dalus.