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 devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
