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

[Michael Schwendt]

On Tue, 1 Sep 2015 11:58:07 -0400 (EDT), Tomas Mlcoch wrote:

> RPM itself expects epoch to be number:
> https://github.com/rpm-software-management/rpm/blob/140744377b019e0de81d76d0931c32228d2ed57e/lib/rpmvercmp.c#L124-L143
> 
> YUM expects epoch to be integral number:
> https://github.com/rpm-software-management/yum/blob/e17424b34ed8409803b5e702b24f6d0051ca99ca/yum/rpmsack.py#L922
> 
> Fedora's doc states that "Epoch" is numeric field:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_Epochs
> 
> 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.
>

It is beyond my time and energy to "fight" bad package updates that don't
fix the problem:

  https://bodhi.fedoraproject.org/updates/FEDORA-2015-735f979d01

What the new createrepo_c in that update does, it ignores the broken
Requires altogether, skips it and doesn't add it to the repo metadata [1].

Effectively, it hides the problem even more than before when it replaced
the unescaped RPM macro with a '0', changing the dependency on-the-fly,
pretending that there is no problem when in fact it's broken in the binary
package that cannot be installed.

Hiding such breakage from the metadata hides it also from depsolvers and
tools like repoclosure that work on the metadata themselves before passing
a transaction to RPM. They would _not_ be able to find such a problem.

IMHO, this is bad as before. I cannot estimate how often an unescaped
epoch macro will break deps in the future again, but a package like that
should not be published with repo metadata pretending that everything
would be fine. If you fear that createrepo_c exiting with error condition
*instead* would happen too often, then apparently the problem is perceived
as an even worse one. Hard to believe.

The corresponding RFE for "rpm" is: https://bugzilla.redhat.com/1251453

[1]

--- d851a23707b6978a0f4ad1439a0b10e2f7d99942be129b12bcde0a7bcb106e0c-primary.xml.OLD	2015-10-22 00:45:03.000000000 +0200
+++ 944af4952f9642bfe6dc2643866de0befd3415373f459be22f898041c69ac83f-primary.xml2015-10-22 00:45:33.000000000 +0200
@@ -109,7 +109,6 @@
       <rpm:entry name="blktap-devel(x86-64)" flags="EQ" epoch="0" ver="3.0.0" rel="3.fc23.git0.9.2"/>
     </rpm:provides>
     <rpm:requires>
-      <rpm:entry name="blktap(x86-64)" flags="EQ" epoch="0" ver="3.0.0" rel="3.fc23.git0.9.2"/>
       <rpm:entry name="libblktapctl.so.0()(64bit)"/>
       <rpm:entry name="libvhd.so.0()(64bit)"/>
     </rpm:requires>