Description of problem: SELinux policy which comes with current 389-admin will not be installed correctly when updating from earlier version of 389-admin which needed 389-admin-selinux. Version-Release number of selected component (if applicable): Update from 389-admin-1.1.11-0.1.a1.fc13 with 389-admin-selinux-v1.1.11-0.1.a1.fc13 to 389-admin-1.1.11-0.6.rc2.fc13 (which replaces 389-admin-selinux). How reproducible: Install 389-admin and 389-admin-selinux from core reop and update 389-admin to latest version of updates-testing repository. Steps to Reproduce: 1. yum install 389-admin 389-admin-selinux 2. 'semodule -l | grep dirsrv' does not contain dirsrv-admin due to bug #570912 3. yum update --enablerepo updates-testing 389-admin 4. yum will install 389-admin, install SELinux policy and remove 389-admin-selinux because current 389-admin in updates-testing contains SELinux policy Actual results: yum installs the SELinux policy correctly but removes it when erasing old 389-admin-selinux (i guess because the uninstall routine of the package tells to remove the police?). Expected results: The SELinux policy should be installed after updating. Additional info: Workaround: semodule -s targeted -i /usr/share/selinux/targeted/dirsrv-admin.pp
Nathan, perhaps this is related to the problem in 389-ds-base when upgrading from 1.2.6 alpha or rc to the latest 1.2.6 rc7 with selinux.
(In reply to comment #1) > Nathan, perhaps this is related to the problem in 389-ds-base when upgrading > from 1.2.6 alpha or rc to the latest 1.2.6 rc7 with selinux. I think the dirsrv module is installed in that case (it's just the relabelling via fixfiles that fails). This issue seems to be a bug in the 389-admin-1.1.11-0.1.a1 spec file where it things that the dirsrv-admin policy module should be removed since the 389-admin-selinux subpackage is being removed. It does not detect that this is indeed an upgrade since there is no new 389-admin-selinux being installed (the selinux module was merged into the 389-admin package). I don't think that there is an easy way to fix this as the bug is in the .a1 spec file. I think we should just release note this as it will only affect those running the early alpha builds where we had a separate selinux subpackage.
It would be possible - but not very elegant - to rename the new SELinux module. But maybe it conflicts with the old module, which would have to be removed before. Not a very nice workaround. Would incrementing the module version solve the problem? Both modules currently have v 1.0.0.
We cannot rename the module without causing other problems. Since the prior version with the spec file bug was an alpha release, it does not seem worthwhile to try to fix this. This issue should not be a problem when upgrading from any prior stable versions.