Description of problem: The following error was reported during a yum update: Cleanup : cyrus-sasl-2.1.23-4.fc12.i686 41/66 groupdel: group 'saslauth' does not exist Non-fatal POSTUN scriptlet failure in rpm package cyrus-sasl warning: %postun(cyrus-sasl-2.1.23-4.fc12.i686) scriptlet failed, exit status 6 Version-Release number of selected component (if applicable): Updating from cyrus-sasl-2.1.23-4.fc12.i686 to version 2.1.23-6.fc12.i686 How reproducible: Always Steps to Reproduce: 1.yum update 2. 3. Actual results: Errors output above. Also, no user or group saslauth exists after the update. Expected results: No errors. Also, should user and group saslauth exist after the update? Additional info: During the update process, user and group saslauth get created, but are deleted before the update process completes (by the %postun scriplet). The non-existence of group saslauth is caused by userdel deleting the group due to USERGROUPS_ENAB being enabled in /etc/login.defs. I presume the user/group saslauth should still exist after the installation/update process. I note that other packages do not delete any created user/group in the %postun scriptlet.
*** Bug 572283 has been marked as a duplicate of this bug. ***
The problem really is that cyrus-sasl package scripts do the following; in %pre: /usr/sbin/groupadd -r saslauth 2> /dev/null || : /usr/sbin/useradd .... saslauth 2> /dev/null || : .... and unconditionally in %post: .... /usr/sbin/userdel saslauth /usr/sbin/groupdel saslauth Now yum has an ordering "Install" followed by "Cleanup" and all of the above results only in a churn after which neither saslauth group nor saslauth user exist. Fixing that with current packages installed will be, ahem, "interesting". Besides such operations in %post should be also terminated by "2> /dev/null || :" although with that it would be much harder to notice that something went haywire.
If the userdel and groupdel are removed from %post in the next version, say N, then when N+1 is installed, the user and group will no longer be removed. Of course, this idea requires that any system have two future updates installed, so it might be necessary to release update N, and then a week later issue an update N+1. Or could release N+1 1 day after N, for those who do daily updates, release N+2 a week later, and N+3 a month after N. That should catch most people. If such a fix could be applied to F-13 very quickly, then at least F-13 would be resolved for all fresh installs once released. Is there a conditional way of removing the user account? For example, can one test if there is another version of the package installed, and only remove the account if this is the removal of the last package? For example (in bash syntax because I don't understand packaging): num_pkgs=`rpm -q cyrus-sasl | wc -l` if [ $num_pkgs -le 1 ] then /usr/sbin/userdel saslauth /usr/sbin/groupdel saslauth fi I'm sure there are neater ways, but it's just a thought.
I've just noticed that abrt uses getent to conditionally create an account/group only if they don't already exist. Presumably that could also be used for conditionally removing the group only in case userdel hasn't already removed it.
*** This bug has been marked as a duplicate of bug 572399 ***
(In reply to comment #3) > > I'm sure there are neater ways, but it's just a thought. See section "9.4.5. Defining installation scripts" of RPM Guide, http://fedora.redhat.com/docs/drafts/rpm-guide-en/ and Table 10-3 in particular. A removal of a group and a user should be guarded by 'if [ "$1" -eq 0 ];". Maybe a trigger could be uses to get around the current situation but I really do not know that.