[Rpm-maint] [RFC] Post-installation Actions for Collections of Similar Packages

[Steve Lawrence]

Based on our previous discussions, we plan to rewrite SELinux support
for RPM by moving policy into separate packages, out of the associated
application packages. By doing this, we can leverage the existing PRCO
for policy installation. However, this design change leads to some
problems that must be resolved.

One problem is the lack of support for performing a single action after
the installation of packages containing similar elements. For example,
with SELinux, all policy modules must be installed in a single SELinux
transaction, even though the modules may be in separate packages. Other
common elements, such as fonts, have similar issues in which a single
action (/usr/bin/fc-cache), only needs to be performed after all fonts
are installed. Currently, these same actions are wastefully performed
multiple times due to limitations in RPM. The ability to perform a
single action after similar packages have been installed can eliminate
the unnecessary duplication of these actions, as well as enable better
support for SELinux.

Our solution is to add a new tag (Collections) to the Preamble section
that can specify one or more collections that a package belongs to.
This tag notifies RPM what actions to take once everything in the
collection is installed. For example, if a package contains fonts,
icons, and SELinux policy, it would specify the following in the
preamble:

    Collections: font icon sepolicy

During package ordering, RPM keeps track of which packages are members
of a collection and marks which of each collection will be the last to
be installed. We need to keep track of this because, in the case of
SELinux, the collection action must be performed as early as possible
(i.e. right after all policy packages have been installed). If we simply
waited until the end of the transaction to run the collection actions,
policy wouldn't be installed until the end, and files that had already
been laid down would likely have incorrect labels.

Immediately after a package has been installed and RPM exits the PSM,
RPM checks if the package is the last of a collection, as determined in
the ordering section. If it is last, RPM then dlopen()s a 'plugin' and
calls a function that provides functionality for the specified
collection. The plugin to open is the same as the collection name. For
example, the following plugins may exist:

    # ls %{_rpmconfigdir}/collections/
    desktop.so font.so icon.so sepolicy.so

Each plugin would have a post() function that would perform the
appropriate actions. This also easily lends itself to more hooks, such
as a pre() function, though we have no use for such a function at this
time.  

The reason we use a plugin architecture, and not just simple
macros/scripts, is because of the amount of information needed in order
to install SELinux. Much more must be done for SELinux modules to be
installed than just running a single command. The appropriate flags and
files need to be passed to semodule (-i to install a module, -r to
remove, etc.). Additionally, after policy is installed, file contexts
must be reloaded within RPM. By allowing access to some of the RPM
internals, this plugin architecture that possible..

This does mean that RPM will still need to know a great deal of
information about SELinux. However, all the necessary logic will be
contained in the sepolicy plugin.