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

[James Antill]

On Thu, 2015-08-06 at 18:37 +0200, Michael Schwendt 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.

 I'd guess it is. I'd say the root bug here is in rpmbuild, this is what
it does for Epoch itself:

    case RPMTAG_EPOCH: {
        SINGLE_TOKEN_ONLY;
        uint32_t epoch;
        if (parseUnsignedNum(field, &epoch)) {
            rpmlog(RPMLOG_ERR,
                   _("line %d: Epoch field must be an unsigned number: %
s\n"),
                   spec->lineNum, spec->line);
            goto exit;
        }

...it should do the same kind of thing for epoch's within E:V-R data
too.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150806/9bed4e03/attachment.sig>