The thing that's missing from this report is the information that yum will potentially use the version of the redhat-release provide to determine the '$releasever' variable, which is very important to yum. See 'man yum.conf':

              distroverpkg The package used by yum to determine the  "version"
              of  the  distribution,  this sets $releasever for use in config.
              files. This can be any installed package.  Default  is  `system-
              release(releasever)', `redhat-release'. Yum will now look at the
              version provided by the provide, and if that is  non-empty  then
              will  use  the  full V(-R), otherwise it uses the version of the
              package.
               You can see what provides this manually by using: "yum whatpro‐
              vides  'system-release(releasever)'  redhat-release" and you can
              see what $releasever is most easily by using: "yum version".

Nothing in Fedora appears to provide 'system-release(releasever)' at present, so yum is looking at the 'redhat-release' Provides:. As fedora-release's redhat-release Provide is unversioned, it uses the version of the package - "19", or "20", or whatever - and works OK. But generic-release's redhat-release Provide is versioned, so yum reads that - "19-2", or "20-1" in the 20 case - and that's not a valid $releasever for the mirrorlists, so everything goes sideways.

Confirmed & reproduced here, yum uses 19-2 as $releasever and this breaks all default Fedora repos.


Quoting from yum.conf manpage:

"distroverpkg The package used by yum to determine the "version" of the distribution, this sets $releasever for  use  in  config.  files.  This  can  be  any
installed  package. Default is `system-release(releasever)', `redhat-release'. Yum will now look at the version provided by the provide, and if that is non-
empty then will use the full V(-R), otherwise it uses the version of the package.
 You can see what provides this manually by using: "yum whatprovides 'system-release(releasever)' redhat-release" and you can see what $releasever  is  most
easily by using: "yum version"."


I've workarounded the issue also via --releasever 19 and "fixed" it by switching back to the fedora-release packages, which is obviously not possible for a rebranded distro based on Fedora.


rpm -e --nodeps generic-release generic-release-notes generic-logos generic-release-rawhide

sudo rpm -Uhv http://mirror2.hs-esslingen.de/fedora/linux/releases/19/Everything/x86_64/os/Packages/f/fedora-release-19-2.noarch.rpm http://mirror2.hs-esslingen.de/fedora/linux/releases/19/Everything/x86_64/os/Packages/f/fedora-release-notes-19-0.13.noarch.rpm http://mirror2.hs-esslingen.de/fedora/linux/releases/19/Everything/x86_64/os/Packages/f/fedora-logos-19.0.4-2.fc19.noarch.rpm



generic-release packages' Provides should be fixed to redhat-release = 19

I would fix this right now, except the generic-release package is secret sauce. It has a source tarball that contains repo defs, and so on, but the source tarball has no URL and no comment indicating where it comes from. It just magically appears from the Land of Spot every so often.

For fedora-release there's an 'upstream' git repo:

https://git.fedorahosted.org/git/fedora-release.git

but there does not appear to be an equivalent generic-release repo, and I can't see that generic-release is somehow generated from the fedora-release stuff, it seems like it must be separate.

The tarball contains a copy of the spec, so I don't know if it's OK to just edit the generic-release spec file in the pkgs git repo and commit that, or if I need to make the changes in the 'upstream' generic-release bits (wherever they are) and generate the spec from that.

Spot, can you perhaps explain (in the generic-release spec) where the tarball comes from and what's the proper way to change that package? Thanks.

BTW, fedora-release's 'redhat-release' provide has been unversioned since 2006, and generic-release's has been versioned since 2008. Neither changed recently. What changed was yum:

commit d0272d66ad1c36e85facc7deed2408409cfec83a
Author: James Antill <james>
Date:   Tue Oct 15 15:28:51 2013 -0400

     Mostly backwards compat. change to how distroverpkg config. works. BZ 1002977.
    
     This is for rel-eng, now instead of just looking at the version of the
    package which provides the "distro. release provide" we try to parse the
    version out of the packages provides. This allows random verisons for
    the package, which is apparently useful.
    
     Speed of config. loading doesn't seem to be measurable. One change is
    that .conf.distroverpkg is now a list to accomodate the new provide vs.
    the old one. Also if anyone had a package providing redhat-release = blah,
    $releasever is now "blah" instead of whatever the package version was.

How about fix yum so as to increase backward-compatibility and reduce the surprise factor from this change was obviously not thought through?  Say, how about dropping the R part of the VR it infers from a provides, so that this will work with *all* rebranded distros, that provide their own -release packaged modified from the versioned provides in Fedora's generic-release?

I guess the damage is already done for 20, but 19's yum could still have compatibility restored with this small change:

--- config.py~  2013-12-06 12:20:45.000000000 -0200
+++ config.py   2013-12-15 03:42:44.649324740 -0200
@@ -1223 +1223 @@
-        ver  = hdr[getattr(rpm, 'RPMTAG_PROVIDEVERSION')][off]
+        ver  = hdr[getattr(rpm, 'RPMTAG_PROVIDEVERSION')][off].split('-')[0]

(In reply to Adam Williamson from comment #3)

> Spot, can you perhaps explain (in the generic-release spec) where the
> tarball comes from and what's the proper way to change that package? Thanks.

All of the files in it are copied from the fedora-release repo verbatim, except for the docs.

Is the first dash or the last dash the one that you are supposed to split on? 
livecd-creator uses something related to get releasever. In python-imgcreate redhat-release is listed as the package to test against. I was going to change that to system-release to fix bug 1044675, but now see that the yum change would still cause that to be broken.
Maybe we should have fedora-release and generic-release start providing system-release(release) instead of system-release = $version-$release and drop redhat-release?

Bruno, when splitting NVR at dashes, because V and R cannot contain dashes, R is the last and V is the one before last.  In the proposed patch, however, what's being split is a V or VR, so V is first and R is second/last.

Who should we ask to see if the decision not to split into version and release at a - is final? The answer to this will affect what we should use in the provides for redhat-release and system-release.

I asked about this change on the yum list. Hopefully we'll get some guidance there.

The main commit for this is detailed at:
http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=d0272d66ad1c36e85facc7deed2408409cfec83a;hp=ddfce65bd5e4c69dfb5096aed68169edc4d35dd8
There was a fix for this change also:
http://yum.baseurl.org/gitweb?p=yum.git;a=commit;h=a52edb8c83e0006a6c0d3cc6071fb3f539e53d00

It looks like the correct fix for this is to drop versions on the provides. If there isn't a version on the provides, the version from the package is used. I think this is probably the best way to get the desired results.
(Note that bug 1044675 is actually caused by a change in the arguments to yum.config._getsysver .)

generic-release-20-2 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/generic-release-20-2

generic-release-19-3 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/generic-release-19-3

I made new builds for fedora-release, which aren't strictly needed to fix this bug, but which have been changed to account for the yum change. However, it looks like they have some sort of restriction on them and even though I can do the builds, they didn't get tagged into updates-candidate because of a policy violation. So it looks like someone from rel-eng will need to OK those changes.

I compared the archive files for fedora-release and generic-release since a new one is needed for rawhide and things have diverged. The Makefile and specfile in fedora release handle arch specific links for keys differently now. (My guess this was prompted by arm going primary.) Changing the provides for the f19 and f20 versions of generic-release shouldn't make things any worse than now, though in theory there may be reasons to update the f20 version to mimic fedora-release. I'm not going to worry about that now. I am going to look at making a generic-release archive for f21. It would be nice to have a simple way to make it based off the fedora-release archive, but I'm not sure yet if that's practical.

Package generic-release-20-2:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing generic-release-20-2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-23857/generic-release-20-2
then log in and leave karma (feedback).

The rawhide version still needs to be updated to 21. I asked Spot about getting more involved in generic-release and want to have a well defined upstream for generic-release as well as pick up the arch mapping stuff from fedora-release.

After getting an OK from Spot, I put in a fedorahosted request for a git repo for generic-release. I'll get the source for the tarball there. It will be based on a selective combination of the current generic-release and fedora-release tarballs.

generic-release-20-2 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

generic-release-19-3 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

> Who should we ask to see if the decision not to split into version and release at a - is final?

This was pushed entirely from RHEL-7 rel-eng, and I tried to not change anything as I didn't see the point, so if you want to change how the provided version string works you need to speak with them more than "us". It's possible they'll be happy with the active part of the provide just being the version, I certainly got confusing answers about what they wanted and first removed the EPOCH values but now they are included again.

I can understand the desire to have just F19 ignore the release as a temp. fix but I'd _much_ rather have the same releasever algo. over different versions of yum (Think mock/etc. type stuff having problems when pointed at different repos.)

generic-release should be OK in 19 and 20 now. (Rawhide generic-release was still 20, and needs an updated tarball. I expect to have it fixed this weekend.)

I think the main issue is that it would have helped to have more communication about the change. (At least how versions were used. livecd-tools using _getsysver from yum, might not have been expected.)

Also note that this change made another difference between yum and dnf. I pointed this out to the dnf guys in bug 1047049. You probably want to keep them in the loop for any changes of this kind.

I don't see a point in changing the f19 (or f20) versions of yum for backward compatibility at this point.

> I don't see a point in changing the f19 (or f20) versions of yum for backward compatibility at this point.

I beg to differ.  A downstream distro with its own -release package, originally based on generic-release, will be gratuitously broken.  There's no real reason to issue an update for this *-release package, whereas yum is frequently updated (I've had to patch it locally 3 times since the update the broke the F19-based downstream distro I use), so it'd be no big deal to include the patch I proposed, or “unbreak” yum, in the F19 line, would it?

Heck, it would even be advantageous for yum to be reversed in F19 for people upgrading from pre-19 to 19-based generic distros.  After all, it's generally a good idea to start by upgrading yum, but at the point you do, your system is broken, because that yum is incompatible with whatever *-release package you have installed before.  Only when you upgrade to a modified *-release will it work again.  Why force such breakage upon users?  To punish them for using a derivative distro rather than Fedora proper? :-)

There is now a good (based on 21 instead of 20) generic-release build for rawhide.