[Rpm-maint] [PATCH 04/19] Add new %policy section to the spec file format

[Panu Matilainen]

On Tue, 2 Feb 2010, Steve Lawrence wrote:

> The %policy section 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.

Rather than replace %policy with something that has a completely different 
syntax and meaning, just mark %policy as deprecated and use a new keyword, 
%sepolicy comes to mind. The old %policy can be turned into a no-op (which 
is for all practical purposes already is, as it's not possible to use it), 
but leaving it alone will allow packages including it to build.

>
> For example:
>
> %policy
> # policy in this section will be added to the main package
>
> %policy foo
> # policy in this section will be added to the '<mainpackage>-foo' subpackage
>
> %policy -n bar
> # policy in this section will be added to the 'bar' subpackage
>
> The %policy 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

%module is an awfully generic term, and one that I could think of wanting 
to use for other purposes. Some "namespacing" would be preferred, eg 
"%semodule"

>
> 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

Are the cases where the basename of the module can be different from the 
modules internal name in practise? If so, ok... but do use a different 
keyword for it, "Name" gets easily mixed up with the actual package name 
tag.

> Obsoletes: One or more space-separated strings specifying which modules
>           are obsoleted by a module. Obsoleted modules are removed and
>           the new modules are installed. An example of when this might
>           be used is in policy renames. For example, if we renamed
> 		   foo.pp to bar.pp, we would specify that bar obsoletes foo. If
> 		   not specified, it is assumed the module obsoletes nothing.

Shouldn't this information really be in the selinux module itself, with 
(lib)semanage handling it? Requiring rpm to handle policy renames seems 
just wrong to me - rpm might want to know about obsoleted policies 
(depending on other implementation details) but it shouldn't have to
*manage* this.

Or maybe I'm missing something in the big picture...

 	- Panu -