On Wed, Dec 18, 2013 at 18:29:41 -0800, Adam Williamson <awilliam@xxxxxxxxxx> wrote:
On Wed, 2013-12-18 at 14:56 -0600, Bruno Wolff III wrote:While looking at bug 1044675 I noticed that redhat-release is unversioned in fedora-release and versioned in generic-release. I would expect it to be the same in both of these packages. I think it probably makes the most sense to version it for anything that is still using that, but wanted to check if other people had good reasons for doing it one way or the other.I've already looked into this. The only reason I didn't fix it already is that generic-release's tarball is secret sauce, there's no instructions on generating it in the spec file.
Lovely. OK won't rush into anything on this side then. (I might try to figure something out and consult with people to see what they think if I think I figured it out.)
The bug I was looking at was https://bugzilla.redhat.com/show_bug.cgi?id=1040607 , where the redhat-release provide being versioned caused a problem (whereas in your case it was the other way around).
I think both cases are wrong now. I think yum used to do something smarter (or perhaps dumber) about grabbing the version. If I switch over to using system-release I'm going to hit the same problem. The problem I was seeing seems likely to have been triggered by the same yum update. So we'll probably want to make the same changes to system-release that we do to redhat-release.
I agree it makes sense for them to match, to provide maximum similarity
of behaviour, but we shouldn't version fedora-release's as
{version}-{release} if we make them versioned, it appears! Either both
unversioned, or both versioned just {version}, I think.
I assume you mean redhat-release above. fedora-release shouldn't be in a provides.
I'll also see if I can find some documentation on provides for how it is supposed to work regarding version and release.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
