[Rpm-metadata] Zero epoch vs no epoch (patch)

[Jeff Johnson]

On May 8, 2006, at 6:38 AM, Christoph Thiel wrote:

> On Sat, 29 Apr 2006, Panu Matilainen wrote:
>
>>>>>>  - Even if no epoch is specified, the metadata still specifies
>>>>>>    this as "0".  For most code paths this is no problem as for
>>>>>>    all comparisons of version data, a missing epoch is the same
>>>>>>    as a "0"  epoch. This should not be a huge problem and would
>>>>>>    be only a cleanup item for the repodata.
>>>>>
>>>>> what does removing 0-epoch items buy us?
>>>>
>>>> What it buys is support for ancient rpm versions. Remember those
>>>> monstrosities where non-existing epoch is not equal to zero epoch,
>>>> epoch promotion and all that fun? I couldn't personally care less
>>>> about the old rpm versions but there are people who do care, for
>>>> example Dag and Matthias:
>>>> http://lists.freshrpms.net/pipermail/freshrpms-list/2006-April/ 
>>>> 014022.html
>>>>
>>>> Removing those zero epochs from repodata makes yum rather unhappy,
>>>> dunno about smart, so changing the default is not really a
>>>> possibility. But then neither supports the prehistoric versions  
>>>> that
>>>> are of concern here. Attached quick hack of a patch adds a  
>>>> switch to
>>>> turn off adding those artificial zero epochs, using this as
>>>> necessary this should be enough to allow using repodata with full
>>>> rpm 3.0.x - 4.4.x range.
>>>
>>> When we were implementing rpm-md support for our online update
>>> channels, we stumbled over the epoch thingy as well, but had to add
>>> the epoch="0", to keep yum & smart intact. The funny thing we found
>>> was the fact that rpm itself doesn't handel an empty epoch
>>> consistently -- if there is any interest, I'll dig into the rpm code
>>> again to give you the details...
>>
>> IIRC rpm 4.2.1 was the first version of rpm to handle zero vs no  
>> epoch
>> equally and sanely, except for a bug in "freshen" case where it did
>> matter for rpm itself until recently (fixed last year or so).  
>> Other than
>> the freshen issue (which didn't affect depsolvers) I'm not aware  
>> of any
>> *recent* issues wrt epochs. Before rpm 4.2.1 there was the promote- 
>> epoch
>> behavior on by default and whatnot.. a horrid mess especially  
>> thinking
>> about it afterwards :)
>
> I just went through the code of rpm 4.4.5 with our RPM maintainer  
> again
> and we found:
>
> rpmVersionCompare (psm.c):
> => no epoch is smaller than epoch 0
>

rpmVersionCompare is old (and broken).

There are two uses in rpmlib, both tainted with legacy.

One use case is --freshen, which is left exactly as it always has been.

The other use is determining "identical" headers where the header  
SHA1 is
compared before EVR, and the SHA1 comparison invariably determines  
whether
2 headers are exactly identical no mater what EVR is present.

> rpmdsCompare(rpmds.c)
> => no epoch is equal to epoch 0
>

rpmdsCompare is the current paradigm, missing epoch is exactly 0,  
used everywhere consistently,
and its behavior is described as
      Missing or non-specified epoch is treated exactly as Epoch: 0 is.

So what's your issue? Presumably with something other than rpm itself.

73 de Jeff