Worst Mistake when Creating a RPM...

…is overlooking the order in which RPM scriptlets are executed. Ideally, you want the package to behave like this:

• First install: register the service with chkconfig and start it.
• Complete removal: stop the service and unregister it from chkconfig.
• Upgrade: stop the running service, replace the binary, and start the new version, leaving the chkconfig registration untouched.

The tempting shortcut is to skip the upgrade case entirely and assume that combining the removal and installation steps will cover it. In the .spec file, that might look like this:

%post
chkconfig --add my_wow_service
service my_wow_service start

%preun
service my_wow_service stop
chkconfig --del my_wow_service

This works fine as long as the package is only ever installed or removed. During an upgrade, however, this fails badly, because the scriptlets run in a different order than this example assumes:

1. %pre of the new package
2. %post of the new package
3. %preun of the old package
4. %postun of the old package

As a result, an upgrade with these scriptlets leaves the service stopped and removed from chkconfig, which is a real problem.

The fix is to check the first argument ($1) that RPM passes to each scriptlet. RPM supplies a value that tells the script whether it is running during an install, a removal, or an upgrade. Using that value, we can write better scriptlets:

%post
if [ $1 -gt 1 ] ; then
  service my_wow_service restart
else
  chkconfig --add my_wow_service
  service my_wow_service start
fi

%preun
if [ $1 -eq 0 ] ; then
  service my_wow_service stop
  chkconfig --del my_wow_service
fi

That solves the problem above.

Hope you found this useful!