Policy Module Packaging Guidelines (first draft)

Paul Howarth paul at city-fan.org
Fri Aug 4 11:41:27 UTC 2006

Michael Thomas wrote:
> Paul Howarth wrote:
>> Wart wrote:
>>> * 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 think this idea merits some discussion. I tend of think of policy
>> modules as being rather like kernel modules, in that they're things that
>> are useful and usable whilst still under development but that ideally
>> should eventually become unnecessary because they get merged into the
>> main upstream project. So a separate package should be a short-lived
>> package really.
>> I see the merits of having a separate package but I'd be in favour of
>> such packages having to be justified as per kernel modules, along with a
>> roadmap for an upstream merge.
> Is there a concern that the main upstream project will start to get
> bloated with the adoption of all of these individual policies?  I had
> thought of the policy modules as a way to separate the ongoing
> maintenance of the policy file from the main upstream project.  But as
> you point out, if the policy module is only merged upstream once it has
> stabilized, there shouldn't be much maintenance necessary.  I guess I
> can see both sides of the argument, and I don't have much of a
> preference either way.
>>> * 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.
>> I did, but I think the scriptlet code is likely to be so different for
>> different packages that I didn't want to include too much in there on
>> the basis that some people might just cut-and-paste things that aren't
>> necessary.
>> How about I use "restorecon" in one of the templates and "fixfiles" in
>> the other, in order to illustrate that there's no one "right" way of
>> doing it?
> Sounds good to me.

OK, changes now incorporated on the wiki page:


More information about the fedora-selinux-list mailing list