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

Steve Lawrence slawrence at tresys.com
Mon Oct 26 20:20:39 UTC 2009


On Fri, 2009-10-23 at 13:13 -0400, Bill Nottingham wrote:
> Steve Lawrence (slawrence at tresys.com) said: 
> > 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
> > 
> > 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.
> > 
> > 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".
> 
> How do you properly handle conflicts or requirements with various versions
> of the base policy package?

We've realized this is a complicated topic we have not given enough
attention and need to give this a bit more thought. We are open to any
suggestions.

> > %policy
> > %module policy/foo.pp
> >    Name: foo
> >    Types: mls
> >    Obsoletes: baz boo
> > %module policy/bar.pp
> >    Name: bar
> >    Types: strict targeted mls
> >    Obsoletes: foo
> >    Base: yes
> 
> I'm assuming the whitespace is irrelevant here. If it's not, it
> should be.

Your assumption is correct. Whitespace is ignored. The indentation is
only used here to make it clear that those options apply to the %module
directives.

> > RPMTAG_POILCYTYPES:        RPMTAG_POLICYTYPESINDEXES:
> >  0: mls                     0: 0
> >  1: strict                  1: 1
> >  2: targeted                2: 1
> >  3: mls                     3: 1
> 
> So, for every new policy type that gets created, RPM
> would need patched and rebuilt to recognize it?

The types are just string identifiers defined by packagers, and can be
anything packagers want. This means RPM can never recognize a type as
good or bad (all types are valid), but makes it very flexible, allowing
third parties to easily create solutions using custom policy types.

> Bill


More information about the Rpm-maint mailing list