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

[Panu Matilainen]

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 -