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

[Michael Schwendt]

On Thu, 6 Aug 2015 18:00:23 +0000, Zbigniew Jędrzejewski-Szmek wrote:

> > It couldn't find a comment in the source that would tell whether this
> > is by design.
>
> Does this really matter? If it's by design, then the design is wrong.
> If not, than the implementation is wrong.

It doesn't matter much, except that I fear dilettantism related to
handling corner-cases and lack of error handling. :-/  Not verifying
input data is the reason for many security vulnerabilities even.

I thought that in the XML repodata, "epoch=-1" instead of "epoch=0" would
have been possible, too, and would not resolve. (whereas "no Epoch" and "Epoch 0"
are treated as equal by definition)

However, rpmbuild doesn't care much about the EVR in versioned deps.
It accepts weird EVR specifiers, such as

  Requires: badepoch = 1a:2b:3c-4-0-1-2-3

and successfully builds the package, only printing this:

  # warning: line 13: Invalid version (double separator ':'): 1a:2b:3c-4-0-1-2-3: Requires: badepoch = 1a:2b:3c-4-0-1-2-3

It even happily builds a spec file that contains

  Requires: badepoch = -1
and
  Requires: badepoch = -1:1

and createrepo_c turns that into "epoch=-1" ver="1".  *sigh* ;-)

On the contrary, rpmbuild rejects spec files with a non-positive Epoch.
So, errors (even if they may be only corner-cases), propagate through the
various tools causing unpredictable symptoms.

Even after a real undefined %epoch in released packages, one can only
hope that some of this is purely theoretical:

  Requires: %{depname} >= %{depepoch}x:%{depminver}

It's possible today. An accidentally inserted 'x' at the wrong place,
rpmbuild would happily build it, and repoclosure would not detect it
as unresolvable, because in the metadata it becomes epoch="0".