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