Paul Howarth wrote: > I've written up my thoughts on packaging policy modules with applications: > > http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules > > Fire away! Looks good! * s/scrope/scope/ * In the 'separate subpackage' section do you want to add a note about making the -selinux subpackage an entirely new package with its own specfile, instead of a subpackage in an existing spec file? Advantages: Keeps the spec files much simpler and easier to read. Allows for separate maintainers of the main and -selinux packages. selinux packages can be updated without pushing new builds of the main package Disadvantages: Care must be taken to make sure that the selinux package is updated with the main package as needed. What value should be given for the URL and License tags in the spec file? * I like the inclusion of the source files in %doc. That can be extremely useful. * You should note that you can't use 'service myapp condrestart' in %postun to transition a daemon process back to the unconfined domain after the module has been unloaded. You have to first transition the daemon domain, then remove the policy module. Otherwise the process will end up in an odd state and can't be killed until selinux is disabled: %postun selinux /usr/sbin/setsebool %{name}_disable_trans 1 /sbin/service %{name} condrestart > /dev/null 2>&1 || : for selinuxvariant in %{selinux_variants} ; do /usr/sbin/semodule -s ${selinuxvariant} -r mymodule &> /dev/null || : done * How should the selinux policy module be versioned? Should it match the application versioning? Are there any restrictions on policy module version numbers? * Using %{name} instead of 'myapp' in the templates would make it easier to copy/paste them into existing packages * Don't you want to call 'fixfiles -R' in the %post and %postun sections of the sample templates? You included it in the scriptlets section above. --Mike -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
