using right address this time..
2011/3/6 Per Øyvind Karlsen <peroyv...@mandriva.org>:
> 2011/3/6 Jeff Johnson <n3...@mac.com>:
>>
>> 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}.
> I prefer for it to be added in same fashion as epoch, it being the least
> significant value, omitting it for provides only using %{version}-%{release}
> provides EVR will then be okay as well if one wants.
>
> I at least personally prefer this logic to be mostly consistent with the rest,
> and also easiest to grasp and packagers to customize.
>>
>> 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.
> Mostly just adding it to package NEVR only is sufficient for achieving both
> main goals of "identification" and "upgrade".
> Leaving it to packagers to add it to EVR of other provides as they see
> fit seems sensible enough to me at least. :)
>>
>> 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.
>
> --
> Regards,
> Per Øyvind
>
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
