Policy Module Packaging Guidelines (first draft)

[Michael Thomas]

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.

--Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20060801/b5934b83/attachment.bin>