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.
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.