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

Steve Lawrence slawrence at tresys.com
Thu Mar 4 21:27:10 UTC 2010


On Thu, 2010-03-04 at 11:31 +0200, Panu Matilainen wrote:
> 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"

We're fine with namespacing.

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

In practice, the basename and module name are the same, but this has
never been a requirement before. We'll have to make sure adding that
requirement doesn't break anything, but it doesn't look like it should
be a problem, allowing us to drop the Name option altogether.

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

This is an interesting idea. We'll have to give this some more thought
and get back to you.

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


More information about the Rpm-maint mailing list