On Mar 6, 2011, at 9:42 AM, Jeff Johnson wrote:
> Under #ifdef RPM_VENDOR_MANDRIVA please.
>
> The problem you are trying to solve is with aliasing
> for a package identifier, which sometimes has
> Distepoch: and sometimes does not?
>
> If so the patch is mostly in the right place, but a "real"
> solution will be to decide on convention(s) for
> RPMTAG_NAME this is used solely for identification
> RPMTAG_PROVIDENAME this is used solely for assertions
> What is confusing is that those two usage cases have exactly the same string
> values, and adding Distepoch: has confused matters a bit (not in an important
> way).
>
> The convention(s) (that need to be finalized) are implemented
> when RPMTAG_PROVIDENAME is added to a header, not here, where
> you are essentially substituting one alias for the other
> where the real need (imho) is to split "identification" <-> "assertion"
> name spaces cleanly.
>
> Gud enuf for now, and until there's clarity on Distepoch: conventions.
>
Let me underscore what I think needs to be decided.
Distepoch: (and Disttag:) are adding "branding" identifiers. That's
fine for identification purposes.
WHat hasn't been decided is this:
Do you want "branding" throughout assertions too?
i.e. should Distepoch: be added to all dependencies as well as to {N,E,V,R}.
Th benefit of adding is that RPM then continues with identically valued
strings for WYSIWYG meeting package monkey expectations.
The cost(s) of adding "branding" like Distepoch: to assertions are:
1) all package dependencies written in *.spec will need to be changed.
2) depsolver metadata is gonna increase in size with lots and lots of
redundant "branding" strings.
There's no reason a priori why RPMTAG_PROVIDENAME MUST include Distepoch: except
to conform with expectations. Maybe I should encode all dependency strings in
EBCDIC
to prove that point ;-)
Either approach is fine. But atm its all kinda muddled and ad hoc and in need
of clarity.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
