[Rpm-maint] [PATCH 10/19] Add new policy requires tag to spec file format

[Steve Lawrence]

On Thu, 2010-03-04 at 14:52 +0200, Panu Matilainen wrote:
> On Tue, 16 Feb 2010, Chad Sellers wrote:
> 
> > On 2/13/10 1:20 AM, "James Antill" <james at fedoraproject.org> wrote:
> >
> >> On Fri, 2010-02-12 at 15:34 -0500, Steve Lawrence wrote:
> >> , or installs something which obsoletes/conflicts with it
> >> etc. IMO putting gpg keys into the rpmdb was a big mistake, and we've
> >> had to work around it at higher levels ... your pseudo packages would be
> >> even worse as they would have full (and separate) prco data with them as
> >> well as just data.
> >>
> > We did indeed follow the lead of gpg keys. If the implementation of gpg key
> > pseudopackages was a mistake, then so is this. We've tried our best to
> > conform to the rpm way of doing things, but perhaps that was a mistake here.
> 
> What rpm does now doesn't necessarily reflect how it should do something 
> :) The gpg keys are one such item - although there *are* some pros to 
> having them in the rpmdb, they're an ugly special case in many ways and 
> the plan is to get rid of them. Since 4.6.0 rpm can take gpg keys from 
> external source but the rest of the work still remains undone.
> 
> >>> Rpm doesn't guarantee ordering. It tries its best, but there are no
> >>> strict ordering constraints to ensure that policy is installed at the
> >>> correct time. Ordering is very important with respect to when policy is
> >>> installed, which rpm can't currently provide.
> >>
> >>  Please define what you mean here, as far as I know the only ordering
> >> problem rpm has "ever" had is ordering on removal of packages -- and
> >> that is now fixed.
> >
> > Perhaps my understanding is wrong here. I thought rpm does not guarantee
> > order. It tries to order things in dependency order, and it guarantees that
> > all dependencies will be installed by the end of the transaction, but it
> > does not guarantee order. I thought this was necessary to handle things like
> > circular dependencies. My understanding was that rpm would arbitrarily break
> > these circles. Was I misunderstanding this?
> 
> Depends how you define "guarantee". There's no way to order a circular 
> dependency except by cutting it, all rpm can do there is try to minimize 
> the damage from breaking loops: installing the whole circular set together 
> in best-effort order using Requires(pre) and such as hints.
> 
> >>  I worry a lot that you'll eventually need all the features of rpm
> >> transaction ordering
> >
> > Note that the policy install itself is orderless - it's a single
> > transaction. We've worked hard in SELinux to ensure that policy operations
> > could be done in a transactional way, and a goal of this is to be able to
> > utilize that.
> 
> Ok, if selinux handles the details of policy operations internally, 
> rpm's ordering doesn't make much difference here.
> 
> > Our --nopolicy patch doesn't use pseudopackages. We store that with the
> > parent package.
> >
> > Regardless, the dummy package is bad because it's not only a hack but it's
> > one that the user has to worry about to install a package. Pseudopackages
> > may not be the best implementation of this (given your disdain for gpg key
> > pseudopackages), but they are at least a detail that the user doesn't have
> > to worry about. Splitting this out means that all users now have to worry
> > about this as well.
> 
> What I wonder here is: should the installed policies be recorded in the 
> rpmdb at all? SELinux has its own storage for tracking installed 
> policies/modules, and if these are not to be removed on package removal... 
> This is somewhat analogue to users and groups added by packages - they are 
> typically not deleted on package removal, also because of security issues 
> (although this is up to package scripts, not controlled by rpm).
> 
>  	- Panu -

We need to store some information in the database outside of what has
been installed. For example, we eventually will need the ability to
switch policy types (e.g. from targeted to mls). To do this, we need to
know what types the current modules can be installed into (via the Types
option). So we need to store the types data in the database.

We also need to know which package provided a module so that we can
correctly determine conflicts, even after the package that provided the
module is removed.