[Rpm-maint] [PATCH 08/19] Remove duplicates when preparing the policy set

[Steve Lawrence]

On Fri, 2010-02-05 at 12:31 -0500, James Antill wrote:
> On Tue, 2010-02-02 at 15:25 -0500, Steve Lawrence wrote:
> > There are cases where duplicates are expected, and we must be able to
> > removed the older version of a duplicate. Unfortunately, policies are not
> > versioned, so we must use the install time of a policy to determine which
> > which is newer. Policies that have not yet been installed get a time of
> > UINT_MAX so they are seen as the newest when compared to already installed
> > policies. In the case of two policies having the same install time, we
> > don't know which one to choose, so we error out.
> > 
> > Policies are only considered duplicates if they have the same name and
> > their types overlay. For example, this would not be considered
> > duplicates because their types do not overlap and could be installed at
> > the same time (in different types) without a problem:
> > 
> > 	%policy package1
> > 	%module modules/foo-targeted.pp
> > 		Name: foo
> > 		Types: targeted
> > 
> > 	%policy package2
> > 	%module modules/foo-mls.pp
> > 		Name: foo
> > 		Types: mls
> > 
> > Whereas this would be considered a duplicate:
> > 
> > 	%policy package1
> > 	%module modules/foo.pp
> > 		Name: foo
> > 		Types: targeted mls
> > 
> > 	%policy package2
> > 	%module modules/foo-mls.pp
> > 		Name: foo
> > 		Types: mls
> >
> > Note: If 'targeted mls' were changed to 'default', that would still be
> > considered a duplicate, because 'mls' is in the set of 'default'.
> 
>  This, along with the previous magic packages and the "obsoletes policy"
> code ... all make me think policies should be in specific packages with
> real nevr and prco information.
> 
>  For instance your "policy obsoletes" must need to reorder the
> transaction, but obviously rpm isn't going to use it for that (where it
> would use prco data).

No reordering needs to take place. The %policy obsoletes is specific to policy
modules. It has no effect on packages. If a %policy module is obsoleted,
then we just remove it when we execute semodule. No ordering needs to
take place.

>  And the above looks like if "%policy pkg1" was in pkgA and "%policy
> pkg2" was in pkgB this code will start doing really weird things (even
> on downgrades! Because the uninstalled policy will be "newer").
> 

I'm not sure I understand the issues. Downgrade should still work, with
the policy from the downgraded package replacing the previously
installed module.