[Rpm-maint] [PATCH 2/6] Add new %sepolicy section to the spec file format

[Steve Lawrence]

On Mon, 2010-07-26 at 13:57 +0300, Panu Matilainen wrote:
> On Wed, 14 Jul 2010, Steve Lawrence wrote:
> 
> > The %sepolicy section is used to describe SELinux policy to be included
> > in a package. It's syntax is similar to other sections (%files, %pre,
> > %post, etc.) in that you can provide a string and -n after the
> > declaration to specify policy should be added to a subpackage.
> >
> > For example:
> >
> > %sepolicy
> > # policy in this section will be added to the main package
> >
> > %sepolicy foo
> > # policy in this section will be added to the '<mainpackage>-foo' subpackage
> >
> > %sepolicy -n bar
> > # policy in this section will be added to the 'bar' subpackage
> >
> > The %sepolicy section contains zero or more %module directives, each of
> > which specifies a path into the build directory of a policy file, for
> > example:
> >
> > %module policies/foo.pp
> > %module policies/bar.pp
> >
> > After each %module directive can be zero or more options, specified in
> > the same format as Preamble tags. The current options are:
> >
> > Base:   Whether or not the module is a base module. Values can be
> >        yes/1 or no/0. Defaults to no/0 if not given.
> >
> > Name:   The name of the module. If not given, we assume the name is
> >        the basename of the module file with file extensions removed.
> >
> > Types:  One or more space-separated strings specifying which policy
> >        types the module can work with. To explicitly state that a module
> >        can work with any policy type, "default" can be specified as
> >        the value. If not specified, we assume the module can work with
> >        any policy type, and assign the types as "default".
> >
> > Spaces before and after the %module directive and options are ignored.
> > Options always apply to the previously defined %module directive.
> >
> > Below is an example of this new format:
> >
> > %sepolicy
> > %module policy/foo.pp
> >   Name: foo
> >   Types: mls
> > %module policy/bar.pp
> >   Name: bar
> >   Types: strict targeted mls
> >   Base: yes
> 
> Since these are "options", why not actually make them options to the 
> %module directive? Eg
> 
> %module -n foo policy/foo.pp
> 
> %module -n bar -b policy/bar.pp
> 
> ..where -n stands for the optional name, and -b for "base". Types might 
> make more sense as it is, but OTOH "-t strict,targeted,mls" would be just 
> as well I think. Also offloading the option parsing to popt should 
> simplify the code somewhat too.
> 
> Especially I'm concerned with the overloading of "Name", I didn't look up 
> the code whether it ends up redefining %{name} macro (which would likely 
> break some specs) or not, but in any case it looks like an unnecessary 
> ambiguity.
> 
>  	- Panu -

The code doesn't redefine the %{name} macro, but we have no problem
making the change. You're right in that it should simplify the parsing
quite a bit. We'll make this change.

- Steve