[Rpm-maint] [PATCH 04/12] Add new %policy section to the spec file format
james at fedoraproject.org
Tue Oct 27 16:48:49 UTC 2009
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 .
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
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
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>
More information about the Rpm-maint