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

[James Antill]

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.

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

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.

-- 
James Antill <james at fedoraproject.org>
Fedora