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.