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

[Steve Lawrence]

On Wed, 2010-06-23 at 11:13 +0300, Panu Matilainen wrote: 
> 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:

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.

> 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

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>

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


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