On Fri, 28 Aug 2015 18:06:27 +0200, Ralf Corsepius wrote:
>>> See:
>>>
>>>
https://lists.fedoraproject.org/pipermail/devel/2015-August/213209.html
>>>
https://lists.fedoraproject.org/pipermail/devel/2015-August/213208.html
>>
>> Bugs ... an undefined epoch is supposed to be treated as 0.
>
> No, that's the old case. No Epoch = Epoch 0.
>
Both cases are equal on the rpm level.
All tools which use rpm need to set their internal representation of an
epoch to 0 if rpm returns an undefined epoch.
It seems to me we're talking past eachother. It would be wrong to assume
that the undefined %{epoch} is supposed to 0.
If rpmbuild rejected a spec file that uses %epoch without defining an
Epoch tag, that would be fine. So far, it doesn't.
$ rpm -qpR blktap-devel-3.0.0-3.fc23.git0.9.2.x86_64.rpm |grep ep
blktap(x86-64) = %{epoch}:3.0.0-3.fc23.git0.9.2
https://lists.fedoraproject.org/pipermail/devel/2015-July/212963.html
That's what this topic is about. Substituting the unexpanded macro with
a "0" in the repo metadata tries to hide breakage under the carpet. It
breaks when passing on the packages to RPM.