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.