Red Hat Bugzilla – Bug 46439
Problem of Script Execution Order when upgrading package
Last modified: 2007-03-26 23:46:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-1.4 i686; en-US; rv:0.9.1)
Description of problem:
The Script Execution Order for package upgrade of rpm (at lease 4.02) is:
new-%pre for new version of package being installed
... (all new files are installed)
new-%post for new version of package being installed
any-%triggerin (%triggerin from other packages set off by new install)
any-%triggerun (%triggerun from other packages set off by old uninstall)
old-%preun for old version of package being removed
... (all old files are removed)
old-%postun for old version of package being removed
any-%triggerpostun (%triggerpostun from other packages set off by old un
That is first install new package then erase old package.
But If there is some script in preun, postun or triggerun section in old
package to delete some config lines in some config files, the new config
lines wrote into the config file by new packages will perhaps be deleted by
old packages. For example I have a font package and there is a script in it
to add a FontDir entry into /etc/X11/XF86Config file, if I upgrade this
package, the FontDir entry will be deleted when erasing the old package.
Because the entry in old and new packages are same.
Steps to Reproduce:
1.install a package which will write something into a config file
2.upgrade this package with -U option
Actual Results: then the "something" will be deleted by postun script in
Because the old package was erased right after the new package was installed.
Expected Results: when erasing the old package, any changes made by new
package's script should not be touched.
It seems that we should first erase the old package then install the new
You need to distinguish between the upgrade and erase uses in %preun and %postun
by looking at argv:
if [ $1 == 0 ]; then
<this is where the package erase actions are performed>
<this is where the package upgrade actions are performed>
There are similar, though much more complicated, conventions using $1 and $2
for %triggerun, see the description of triggers in the rpm-devel package for
But it still doesn't explain why the postun section of the RPM is being run
AFTER the newer package is installed (and after the newer package's %post
section is run). My customer is experiencing this as well, and it's biten them
twice. Do you plan to change this behavior?
rpm has always installed before erasing, and this is not going to change.