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

[Panu Matilainen]

On Tue, 22 Jun 2010, Steve Lawrence wrote:

> On Tue, 2010-06-22 at 12:12 +0300, Panu Matilainen wrote:
>> On Mon, 21 Jun 2010, Steve Lawrence wrote:
>>
>>> This patch adds the install-time feature that if a package requires a
>>> package in a collection, then it also requires all other packages in
>>> that collection. This has the effect that collections will be roughly
>>> grouped together during a transaction.
>>>
>>> Although this is not absolutely necessary for the majority of
>>> collections, it is required for the SELinux collection. This is because
>>> all SELinux policies must be installed before the applications they
>>> secure to ensure correct labels. This means we must ensure packages in
>>> the selinux collection are ordered earlier in the transaction than all
>>> applications they protect. Adding this implicit runtime requirements
>>> achieves this in a general manner, without major modifications to
>>> dependency ordering.
>>
>> It can have the effect of creating gigantic dependency loops, causing
>> severe ordering problems elsewhere (playing around with a quick-n-dirty
>> runtime hack to generate ldconfig-collection and subscribing all packages
>> providing sonames to it). In the library-case, the extra grouping makes
>> pretty much everything pre-require everything else and poor rpm ending up
>> ripping them apart again the best it can, with *cough* less than optimal
>> results :)
>
> I hadn't thought of the ldconfig case. I imagine your right.

The ldconfig case is probably close to worst-case scenario, but similar
issues are likely to be present for any "real" packages which have 
scriptlets and dependencies for them.

>> Of course packages with libraries are a wildly different situation from
>> selinux policies. It's quite possible we'll need some additional flags to
>> control collection behavior - some cases absolutely require some special
>> ordering, for others it might be not just unnecessary but actually harmful
>> too.
>>
>> I suppose moving the collection ownership to packages would help here:
>> packages in a collection would then just require the collection owner
>> instead to accomplish rough grouping in ordering without adding too many
>> extra dependency loops. Packages belonging to several collections might
>> prove "interesting" here though...
>>
>
> I don't think requiring the collection owner would help much in the case
> of selinux. It would ensure that the policies get installed after the
> collection owner, but it wouldn't ensure that all policies get installed
> before all applications they protect, which is necessary for labeling to
> be correct.

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:

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.

> I think your flag idea would probably be the best way to enable this
> ordering for select collections. Maybe adding a %collection specific
> option, specified by the owner, e.g.
>
> %collection selinux-policy -o groupCollection -p <plugin:selinux.so>
>
> Though, multiple collection owners with conflicting orderings could be a
> problem. Maybe Conflicts could be used to prevent something like that.
> And I guess that wouldn't be very hard to automatically detect at the
> beginning of a transaction, and just abort early.

Multiple collection owners might be best handled as conflicts anyway... 
but we'll see.

 	- Panu -