[Rpm-maint] [PATCH 11/19] Parse new policy requires header and check policy dependencies

[Panu Matilainen]

On Tue, 2 Feb 2010, Steve Lawrence wrote:

> After a policy set has been prepared (rpmpolsPrepare), a call to
> rpmpolsCheckDeps will determine if PolicyReuqires: dependencies are met.
> This function only checks against packages currently installed.
>
> Also, PolicyRequires are merged into Requires, so if normal dependency
> checks pass, we know the PolicyRequries packages will be installed by the
> end of the transaction.

The policy/module dependencies seem strangely familiar to me... obsoletes, 
conflicts and requires. It should be possible to map them to the existing 
dependency information, adding a parallel set of selinux (or anything else 
for that matter) specific dependencies looks like road to madness to me.

Here's an idea, related to the pseudo-package issue too:

Instead of creating a parallel universe of dependencies and 
pseudo-packages, turn the policy/module bits into transaction elements and 
have them processed business as usual. Something in the lines of: detect 
the presence of selinux modules in a package in rpmtsAddInstallElement() 
create a header of the policy bits and add another transaction 
element for it. That way the dependencies etc will get processed along 
with everything else, instead of requiring a whole new set of things.

Or so the theory goes - sure it's going to need various enhancements here 
and there, such as probably a new element type-bit so added policies would 
be something like (TR_ADDED|TR_POLICY) and filter in various places etc.

And actually the case of pseudo-package generation here is a sub-case of 
more generic "package(s) within a package" idiom which comes up every now 
and then. If the policy parts were stored (at package build-time) in a 
header of their own, nested inside the main package header (a header is 
just binary data and headers can contain such data), 
rpmtsAddInstallElement() could basically just grab the policy header and 
call itself to add another element from it, no need for runtime 
transformations of dependency and other data.

Again, so the theory goes. I've no doubt various internals will need 
tweaking to make it possible in practise.

BTW one very real issue with storing policies in headers (nested or not) 
is that the header size is currently capped at 16MB, and people are 
already hitting that limit occasionally. It takes a huge number of files 
to reach that, but adding arbitrary amount of selinux modules into the 
header is not going to do anything to help. The limit needs raising sooner 
than later anyway, but packages with headers bigger than 16MB will be 
unreadable by every rpm currently deployed, and there's no way to add a 
nice little feature-tracking dependency for it.

 	- Panu -