[Rpm-maint] [PATCH 04/12] Add new %policy section to the spec file format

Chad Sellers csellers at tresys.com
Tue Oct 27 18:36:58 UTC 2009


On 10/27/09 12:48 PM, "James Antill" <james at fedoraproject.org> wrote:

> On Tue, 2009-10-27 at 12:24 -0400, Steve Lawrence wrote:
> 
>> We have thought about that, but it has a number of drawbacks.
>> 
>> First, this method would cause close to 200 more packages to be included
>> in standard dependency checks and increase the number of headers that
>> are downloaded for things like yum. While not a crippling number,
>> historically there have been reservations about the size and processing
>> increases this could create [1].
> 
>  200 just isn't a big number anymore. See the recent texlive split in
> Fedora -- 4,000 new packages.
> 
>> More importantly, policy packages need to be treated very differently
>> than traditional packages, much more so than with debuginfo packages.
>> For example, all policies need to be extracted from all policy packages
>> and installed at the same time and at the very beginning of the
>> transaction.
> 
>  This just means they need a Requires(pre) instead of Requires, from the
> package which requires it's policy.
> 
One of the main reasons people have not adopted putting policy in individual
packages is because a policy installation transaction is very expensive.
Having many packages each run a policy installation transaction as they're
being installed is too slow. Consequently, we need to be able to aggregate
all the policies together to install them as part of a single policy
installation transaction. Since the policy has to be loaded before any files
hit disk, we do this at the very beginning of the rpm transaction.

My understanding of Requires(pre) is that it would only affect the ordering
of packages being installed as part of the transaction. So, to use it, we
would have to add appropriate Requires(pre) to each package with policy, let
the rpm transaction begin, then interrupt it after all the Requires(pre)
dependencies had been installed but before any package with policy had been
installed, install policy, and then have the rpm transaction pick back up
where it left off. I know of no good way to interrupt rpm in the middle of
installing packages, but I'm open to any ideas.

>>  This means that for policy packages, the meaning of
>> Requires would need to be changed to 'this packages must already be
>> installed' rather than 'these packages need to be installed by the end
>> of the transaction.' This was the reasoning behind the PolicyRequires
>> directive in later patches.
> 
>  Again, this is what Requires(pre) is for.
> 
>>  Similarly, when a policy package is
>> Obsoleted, we need to special case that and remove policy at the
>> beginning of the transaction, treating obsoleted policy packages
>> differently from obsoleted normal packages. While the special casing of
>> policy packages is doable, it changes the meaning of existing core
>> functionality depending on the package type, which we wanted to avoid to
>> prevent breaking rpm.
> 
>  I kind of understand what you are saying here ... on a rename you want
> the old policy to be gone before you try and load the new policy. But
> there are problems with this:
> 
There's no before and after. We want to run a single transaction that
removes the old and adds the new. This is one of the reasons libsemanage
transactions exist, because we need multiple changes to happen
simultaneously.

> i. The current behaviour should work fine if you rename the policy
> variables/etc. as well as the package name.
> 
> ii. If on (pkgY obsoletes pkgX) you move from:
> 
> 1. install pkgY
> 2. remove pkgX
> 
> ...to:
> 
> 1. remove pkgX
> 2. install pkgY
> 
> ...you have a whole new list of problems, if the transaction dies after
> 1 but before 2, and also for whatever is running between #1 and #2.



More information about the Rpm-maint mailing list