On 1/16/07, Jeff Spaleta <jspaleta@xxxxxxxxx> wrote:
On 1/15/07, n0dalus <n0dalus+redhat@xxxxxxxxx> 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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
