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

[Panu Matilainen]

On Thu, 1 Apr 2010, Steve Lawrence wrote:

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

Nod, this is one case of the "delayed one-shot triggers", IIRC in dpkg 
terminology these are called "named triggers" to which packages 
explicitly "subscribe" to, "file triggers" behave the same except that 
they're automatically tracked through paths in packages (eg a package 
automatically subscribed to "font collection" by just containing 
/usr/share/fonts/.*\\.ttf etc files)

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

While the talk around "update cache just one" etc mechanisms tends to 
revolve around doing stuff after the transaction completed, there's no 
requirement for it to be that way for any of them: run after all related 
transaction elements have gotten processed (installed or erased) is just 
fine for all of them. The requirement of getting the related packages 
installed as early as possible might be a bit unique to SELinux but I dont 
think it would *hurt* any of the other cases either - there are usually 
a vast number of valid orderings for a package set.

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

Plugins are good. It's possible to maintain them outside of rpm and avoid 
dragging in extra dependencies to the rpm core.

We dont really want all of the simple "run this command once" cases as 
separate plugins though, packagers need to be able to supply these things 
as scripts for the relatively simple cases. Possibly that could be just a 
(built-in) "single command" plugin that eats interpreted scripts / command 
lines, in spirit of "make easy things easy and hard things possible."

 	- Panu -