Description of problem: Noticed that selinux-policy and selinux-policy-targeted are no longer installed, while researching bug 185083. Version-Release number of selected component (if applicable): current versions after re-installing selinux-policy and targeted: # rpm -qa|egrep 'sel|libse|kernel|yum|piru|rpm'|sort kernel-2.6.15-1.2039_FC5 kernel-2.6.15-1.2041_FC5 libselinux-1.29.7-1.2 libselinux-python-1.29.7-1.2 libsemanage-1.5.28-1 libsepol-1.11.18-2 libsetrans-0.1.18-1.2 pirut-1.0.1-1 rpm-4.4.2-15.2 rpm-libs-4.4.2-15.2 rpm-python-4.4.2-15.2 selinux-policy-2.2.23-15 selinux-policy-targeted-2.2.23-15 yum-2.6.0-1 yum-utils-0.5-1 How reproducible: This did not happen on another machine. Steps to Reproduce: 1. Install FC5T2 2. pup daily Actual results: # rpm -qa|grep sel # (nada) Expected results: selinux-policy-2.2.23-15 selinux-policy-targeted-2.2.23-15 Additional info: I am really sure that I *never*: 1. used rpm manually to remove the two packages. 2. used yum manually to remove the two packages.
Created attachment 125986 [details] As you can see, the two packages were not present in rpm -q, and the yum log does not indicate they were removed, yet they weren't there. A pirut install shows in the yum.log and rpm -q OK.
Did you see any scriptlet errors? Unfortunately, scriptlet errors in %pre will lead to packages not being installed :-/
All package transactions have been performed with pup. Is there a location where failed pup/yum/rpm transactions log their failures ? If the package was already installed (as in this case), are you saying that a scriptlet error will lead to packages being incorrectly uninstalled. Looking at it more closely, would it make sense for the whole transaction to fail, and be left back where you started, rather than with an incomplete installation (that wasn't the fault of the user) and whom hasn't been informed that somwthing went wrong ? Is it only the rpm database that is affected, or are the files on disk likely to be missing as well ? As you would need a log of any possible scriptlet errors to solve issues like this it seems a good idea would be to log any "bads" in maybe the yum log or a separate rpm log ?
I don't think I've hooked things up yet so that the errors end up in the yum log as well as the console -- this is something which needs doing on the yum level. But they do end up in your xsession errors file or wherever. And yes, this is a very crappy area of rpm :-/
This should be happier now and have more logging.