Undefined %epoch problem (Re: rawhide report: 20150730 changes)

[Tomas Mlcoch]

----- Original Message -----
> On Fri, 28 Aug 2015 04:12:20 -0400 (EDT), Tomas Mlcoch wrote:
> 
> > > On Thu, 06 Aug 2015 13:15:02 +0000, Igor Gnatenko wrote:
> > > 
> > > > We discussed with Jan Silhan yesterday. It looks like something broken
> > > > in
> > > > createrepo/createrepo_c in F22. So it's not dnf/yum/hawkey/libsolv
> > > > issue.
> > > > 
> > > > LOG: https://ignatenkobrain.fedorapeople.org/epoch_bug.log
> > > > 
> > > > Also CCing Jan.
> > > 
> > > Wow. createrepo is also affected.
> > > 
> > > createrepo_c uses strtol() to accept only numbers as Epoch.  Anything
> > > else strol() cannot parse is ignored and defaults to "epoch=0" in the
> > > repo metadata. This means it can break for typos as well as, not just
> > > an undefined macro used as Epoch in a versioned dep.
> > > 
> > > It couldn't find a comment in the source that would tell whether this
> > > is by design.
> > 
> > 
> > Hi Michael,
> > 
> > what do you suggest?
> > I can think about three reasonable solutions for createrepo_c here:
> > 
> > 
> > 1) Abort and print error about bad (non-numerical) epoch
> 
> > 2) Print warning about the bad epoch
> 
> > 3) Print warning about bad epoch and skip the broken dep
> 
> > X) Ignore the broken package
> 
> Why are only numerical Epoch values accepted?
> 
> What would break, if an Epoch recognized as "bad" would be replaced
> with a string such as "-BROKEN-"? epoch="-BROKEN-" in the primary metdata.
> 
> The version tags "ver" and "rel" attributes may also be non-numerical.
> Why not "epoch", too?
> 
> Else I think rpmbuild may be able to reject more non-numerical Epochs,
> but as long as it doesn't, replacing an Epoch is wrong.
> 
> Other layers that could watch for non-numerical Epochs: rpmlint + AutoQA.
> 

RPM itself expects epoch to be number:
https://github.com/rpm-software-management/rpm/blob/140744377b019e0de81d76d0931c32228d2ed57e/lib/rpmvercmp.c#L124-L143

YUM expects epoch to be integral number:
https://github.com/rpm-software-management/yum/blob/e17424b34ed8409803b5e702b24f6d0051ca99ca/yum/rpmsack.py#L922

Fedora's doc states that "Epoch" is numeric field:
https://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_Epochs

This rpmbuild acceptance of a non-numerical epoch is obviously a bug.
I would prefer one of my proposed solutions instead of accepting non-numerical epoch values.