Description of problem:

The iptables-1.4.7-9.el6 RPM added "alternatives" functionality to the package moving its /lib*/xtables directory.  Normally upon upgrading to this package, the old /lib*/xtables directory is replaced with a symlink pointing to /etc/alternatives/lib-xtables.%{_arch}.

However, if we install custom iptables plugin files in /lib*/xtables, when we do "yum upgrade" that upgrades us to iptables-1.4.7-9.el6, the /lib*/xtables symlink does not get created.

The "alternatives" command should have failed when it couldn't create the slave symlink?  The iptables package should detect that all of its symlinks weren't created.


Why doesn't "alternatives" report this failure to create some of the package's slave symlinks?

Version-Release number of selected component (if applicable):

iptables-1.4.7-9.el6

How reproducible:

Always
  
Actual results:

Here's showing the alternatives command not detecting the problem:
========
$ ls -l /lib64/xtables
lrwxrwxrwx. 1 root root 36 Mar 16 13:25 /lib64/xtables -> /etc/alternatives/lib-xtables.x86_64/
$ sudo rm /lib64/xtables
$ sudo mkdir /lib64/xtables
$ sudo alternatives --auto iptables.x86_64
$ echo $?
0
$ ls -l /lib64/xtables
total 0
========

Expected results:

I can put it back with:
========
$ sudo rmdir /lib64/xtables
$ sudo alternatives --auto iptables.x86_64
$ ls -l /lib64/xtables
lrwxrwxrwx. 1 root root 36 Mar 16 13:38 /lib64/xtables -> /etc/alternatives/lib-xtables.x86_64/
========