[Rpm-maint] [PATCH v2 3/5] Add common Collection requirements

[Panu Matilainen]

On Wed, 23 Jun 2010, Steve Lawrence wrote:
> On Wed, 2010-06-23 at 11:13 +0300, Panu Matilainen wrote:
>>
>> Hmm, this sounds somewhat familiar... isn't this basically a case of "if
>> these packages are present in transaction, order them before me but do not
>> actually require them"? The kernel/initrd folks have been requesting such
>> a feature for a long time. If we can do this in a way that serves both,
>> all the better.
>>
>> Not sure if you've decided something concrete on the outcome of the
>> previous selinux policy packaging discussion (thread starting at
>> http://lists.rpm.org/pipermail/rpm-maint/2010-April/002698.html) but for
>> at least some of the variants something like this seems workable:
>
> Yes, we've decided we would split all policy into a separate *-policy
> packages with the main package requiring it. So apache-policy contains
> all policies (mls, targeted, etc) and apache requires apache-policy.

Oh, the main package *requires* the policy? In that case you dont need any 
extra ordering to get policies installed before the apps they protect, rpm 
guarantees requires to be installed before the requiring package (except 
if there are dependency loops, but there shouldn't be those in this case).

The order-hint thingie was under the assumption the policies are not
required (to avoid unnecessarily dragging them in on systems where selinux 
isn't enabled). Or was the hard requirement decided just because there is 
no other way to establish the relation in rpm currently?

>> Taking again apache and its policy/policies as an example...
>> If either all the policies are included in a single package, or provide a
>> common thing regardless of the variant, then the main apache package could
>> have something like this (ignore the exact spec syntax for now):
>>
>> Requires(order): apache-policy
>>
>> ...which creates a kind of soft dependency between apache-policy and
>> apachge, which dependency resolution ignores but ordering takes into
>> account as if it were a real dependency, ie anything providing
>> "apache-policy" needs installing before "apache" itself.
>>
>> IF this kind of approach works for selinux policies then it's not even
>> collection specific, it'd be just a common mechanism which collections
>> use, and kernel/initrd folks would be happy too.
>
> It seems like this could work. So if I understand it correctly, a more
> complicated selinux example with two packages, each with a policy, might
> look like this?
>
> foo-policy:
>  Requires: collection(selinux-policies)
>  Provides: sepolicy
>
> bar-policy:
>  Requires: collection(selinux-policies)
>  Provides: sepolicy

Hmm.. are these two providing the same thing on purpose? I don't quite see 
what that would accomplish, except chaos and confusion :)

> foo:
>  Requires: foo-policy
>  Requires(order): sepolicy
>
> bar:
>  Requires: bar-policy
>  Requires(order): sepolicy
>
> selinux-policy:
>  Provides: collection(selinux-policies)
>  %collection selinux-policies -p <plugin:sepolicy.so>

Yeah, that's thereabouts to what I was thinking of (with the exception of 
the "sepolicy" requires/provides which seem redundant and even 
problematic) the necessary clues to order these are already present: the 
-policy packages belong to a collection (thus requiring the collection 
owner), and the main packages require the policies.

The collection-related requires/provides can (and should) be handled 
behind the scenes, so eg

foo-policy:
   Requires: collection(selinux-policies)

is written in the spec as "Collections: selinux-policies" and this creates 
whatever the dependency and other magic is necessary. Ditto for the 
provides from "%collection selinux-policies".

> Which should order the {foo,bar}-policy packages before both foo and bar
> and should trigger the sepolicy plugin at the right time.

So the theory goes :) I've a feeling real world ordering with multiple 
different collections and other packages requiring those main packages etc 
might have some surprising results. I guess only time and experimenting 
will tell, and it might well be the selinux policies want some special 
grouping.

 	- Panu -