[Rpm-maint] [PATCH 04/12] Add new %policy section to the spec file format
notting at redhat.com
Fri Oct 23 17:13:21 UTC 2009
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?
> %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
> 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?
More information about the Rpm-maint