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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
