[Rpm-maint] [PATCH 14/19] Detect possible policy module conflicts

Steve Lawrence slawrence at tresys.com
Fri Feb 12 20:41:08 UTC 2010


On Fri, 2010-02-05 at 12:54 -0500, James Antill wrote:
> On Tue, 2010-02-02 at 15:25 -0500, Steve Lawrence wrote:
> > +       if (rstreq(headerGetString(h, RPMTAG_NAME), RPMPOL_PKG_NAME))
> > {
> > +               pol->source = headerGetAsString(h, RPMTAG_SOURCERPM);
> > +       } else {
> > +               pol->source = headerGetAsString(h, RPMTAG_NAME);
> > +       }
> 
>  While this is much better than "(none)", I'm not sure why you are
> treating different packages from within the same specfile
> differently ... and also SOURCERPM contains NVR, not just name.

We've sort of changed what SOURCERPM means with respect to our pseudo
packages. Perhaps adding a new tag would have been better?

This is how it works:

When we read policy from a package, its source is the RPMTAG_NAME of the
package it came from. We store this name as the RPMTAG_SOURCERPM in
our pseudo policy packages. So in our pseudo packages, SOURCERPM is just
a name, not a NVR.

However, when we read our pseudo packages from the database (where
RPMTAG_NAME == RPMPOL_PKG_NAME) we don't use RPMTAG_NAME as the source
because this is a pseudo package. Its actual source is in SOURCERPM.

So in a pseudo policy package, SOURCERPM doesn't contain NVR, just the
name. We only store the name, and not the whole NVR, because when we
check conflicts we only care about the name, and there doesn't seem to
be a safe way to extract just the name from a NVR. Perhaps I just missed
it.

>  And again, you now have your own "obsoletes, requires and conflicts"
> processing. And frankly the missing provides are probably a bug (having
> packages which don't provide at least their name will be "interesting").
> Just make real packages.
> 

See the previous email.


More information about the Rpm-maint mailing list