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

[Tomas Mlcoch]

----- Original Message -----
> 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
----------

Pros:

* Clearly states that there are erroneous data on input.

Cons:

* For services like Koji, it would break whole repodata generation.
Even a rarely used sub-package that is almost useless and used only
by few users could break repodata generation and block
release of critical security fixes for ALL fedora users
and would require a manual fix (removal of the broken package)
from releng side.

* Bad dep (e.g. bad epoch) doesn't have to necessary break stuff.
For example "provides" are not always used by other packages.
Also for rich deps like "suggests", "enhances", etc. a bad dependency
isn't a big deal and it would be foolish to stall
a security update just because some package has
a broken dependency because that dep may not be used at all.


2) Print warning about the bad epoch
----------

Pros:
* One broken package doesn't block updates.

Cons:
* I don't see any important


3) Print warning about bad epoch and skip the broken dep
----------

Pros:
* One broken package doesn't block updates.
* Output repodata doesn't contain obviously bad data (deps)

Const:
* I don't see any important


Option that is not acceptable:

X) Ignore the broken package
----------

Cons:
* As I said above some deps aren't used at all
and leave a whole package out just because of
a bad dep could make much more mess.


Tomas