On Wed, 2011-06-01 at 10:54 -0400, Eric Paris wrote: > The selinux-policy rpm works by installing a bunch of binary policy > modules and then in post it will call some selinux tools which take all > of the modules along with local user configuration and local user > modules and will build a final binary policy file. This takes a lot of > time and a lot of memory. (In one test we see that this building of the > final binary doubles the memory needed by anaconda during install). > Obviously work needs to be done on these tools to fix both the time and > the memory usage, and there is some traction along those lines but > nothing substantial in the near term. > > Since the vast majority of users don't make any local modules or any > local configuration, I suggest that we include a final version of the > binary policy file inside the RPM built at rpmbuild time marked as a > config file. Thus if a user makes no local changes to selinux policy > the rpm install/update will just drop a new final policy binary into > place and will never locally run the policy compilation tools. > > My suggestion (and here is where I need people who understand rpm) was > that in post we could test for the existence of a .rpmsave final binary > policy file. If we found it we would know that the user had some local > configuration and that their final binary policy was not the same as the > one included inside the rpm. Thus we could delete the .rpmsave and run > the tools to rebuild a final binary policy on the end station. No, don't test for .rpmsave files ... in theory you could do it with md5sums, possible by doing something like: build-selinux-policy -o foo md5sum foo > .foo.md5sum ...at rpmbuild time and then compare that on upgrade (test would need to be done in %pre, but acted upon in %post -- which is horrible). Another option might be to just mark it as "config-noreplace", and then test if you've got the newer version in %post (via. the md5sum method) ... if you haven't got the newer version you'd need to rebuild. Also I don't see how this can work with "externally packaged policy" like pure-ftpd-selinux etc. ... which I thought was "the future". _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list