Description of problem:
Six instances of the following line whenever making changes to the RPM database,
or testing actions that would result in changes with "--test":
error: Macro %__policy_tree has an empty body
I tracked this message down to the file "/usr/lib/rpm/macros", and from there to
the file "/etc/selinux/config" that holds the actual value the RPM macro is using.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Edit "/etc/selinux/config"
2. Set "SELINUXTYPE" to be null (not sure under what circumstances this happens,
but this was how my system was configured after an upgrade from FC3 on which
SELinux was also disabled)
3. Try and install/upgrade an RPM package (even in --test mode)
No errors displayed
The fix is to ensure that "SELINUXTYPE" is always assigned a value in
"/etc/selinux/config", even when "SELINUX" is set to "disabled". Since this
file is provided by both the "selinux-policy-strict" and
"selinux-policy-targeted" packages I think the solution would be to fixed it in
those two RPMs, but it could also be corrected by changing the RPM macro to take
into account the possibility of a null string.
The values permitted for seloinux variables are clearly documented in the file, and none of the permitted
values are null.
I know that a null string is not a permitted value. I initially installed
SELinux with FC3, didn't have time to get it working properly and so disabled
it, but left the policy configured as "targeted" intending to get back to it but
never got around to it. The problem is that when upgrading from FC3 to FC4 with
SELinux configured as above something in the upgrade process sets the value to a
null string, hence the error messages after the reboot.
This is why my original suggestion was that a solution might be to ensure that a
value is set for "SELINUXTYPE" when installing/upgrading the policy packages,
even if "SELINUX" is set to disabled. Uninstalling, removing the config file
and then re-installing the two policy packages does seem to create a valid file,
so the issue may be specific to whatever RPM installation method Anaconda is
using during an upgrade.
This is a selinux configuration, not an rpm, problem. Changing component.