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

[Steve Lawrence]

On Mon, 2009-10-26 at 16:26 -0400, Bill Nottingham wrote:
> Steve Lawrence (slawrence at tresys.com) said: 
> > > > 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.
> 
> It almost sounds like it would be better to create actual packages
> (like debuginfo) and synthesize the requires/provides/obsoletes/conflicts
> there.
> 
> Bill

We have thought about that, but it has a number of drawbacks.

First, this method would cause close to 200 more packages to be included
in standard dependency checks and increase the number of headers that
are downloaded for things like yum. While not a crippling number,
historically there have been reservations about the size and processing
increases this could create [1].

More importantly, policy packages need to be treated very differently
than traditional packages, much more so than with debuginfo packages.
For example, all policies need to be extracted from all policy packages
and installed at the same time and at the very beginning of the
transaction. This means that for policy packages, the meaning of
Requires would need to be changed to 'this packages must already be
installed' rather than 'these packages need to be installed by the end
of the transaction.' This was the reasoning behind the PolicyRequires
directive in later patches. Similarly, when a policy package is
Obsoleted, we need to special case that and remove policy at the
beginning of the transaction, treating obsoleted policy packages
differently from obsoleted normal packages. While the special casing of
policy packages is doable, it changes the meaning of existing core
functionality depending on the package type, which we wanted to avoid to
prevent breaking rpm.

Additionally, the traditional conflicts would not be very useful for
policy packages. Conflicts is generally used when two packages provide
the same functionality but cannot be installed at the same time (e.g.
qmail/sendmail). Rarely does this occur with policy modules. Most
commonly a module obsoletes another module (as in renames), which is
handled by the Obsoletes option in the new %module directive.

- Steve

[1] http://marc.info/?l=selinux&m=114658781128088&w=2