On 1/14/07, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote:
Le samedi 13 janvier 2007 à 12:48 -0500, Mail List a écrit :
> In principal the package could provide and uninstall script which would
> reverse the scripts. THis is of course an additional burdon on the
> maintainer - and well may be a better thing to target enterprise and have
> customer cover the cost.
This would be very hard to do. On post install you know the target state
of the system, but how are you supposed to guess what are you roll
backing to ?
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. Then, when the scripts run to undo the install
script, this data can be used to put things back the way they were
previously (provided they haven't been modified since the install
script ran, which might mean you get .rpmrollback files instead).
The majority of install scripts (eg lots of update-index-x and
ldconfig) could even be replaced by inbuilt macros designed to support
rollbacks. For other packages that do more specialized things in
scripts, the storage mechanism and extra scripts would be required.
If the support was there in rpm and there was consensus that this is a
good feature to put in Fedora, then we could begin by loosely
requiring (unless it is technically not feasible or at all practical)
that new packages support rollback. RPM could detect if a package
supports rollbacks by either the presence of rollback scripts or if
the package uses no scripts or only the new rollback safe macros (we
could make macros like %ldconfig etc) in scripts.
There are also other advantages to having macros like %ldconfig made
in that rpm can use this to optimize updates/installs by only running
ldconfig at the very end, or before any dependent packages are
updated/installed.
Not all the packages would need to be rollback safe for the system to
work nicely. If you wanted to rollback some particular update/install,
as long as all the packages involved in that update/install were
rollback safe there would be no issues with performing a rollback.
Eventually more and more packages (and hopefully any important system
ones) would support rollback. If the user asks rpm to rollback an
update/install that involved a non-'rollback safe' package, rpm could
either; warn the user and ask if it should continue, or just fail with
an error message about the package not supporting rollbacks.
Here is some quick stats from this box:
- Number of packages installed: 1576
- Number of packages containing some kind of rpm script: 731
- Number of packages containing scripts without completely obvious
methods of rolling back*: 192
Essentially this means that all but 192 of the rpms installed on my
machine could have their rpm scripts replaced with macros made to do
the same thing, or involve operations that could be marked (like
%rollback_safe('cmd')) as not needing any rollback. Of these 192, I
don't think there are very many that couldn't be made rollback safe
with small bit of work.
n0dalus.
* I did this by quick visual inspection of the scripts in each package
after dumping them to a big file. I removed any scripts which; only
added users, updated some cache (eg gtk-update-icon-cache), setup a
trigger for prelink, removed .pyc files, created font indexes or
updated info pages, ran ldconfig, chkconfig/service or other init.d
scripts.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
