If you have groups_gz and groups in your repodata, we're unconditionally preferring group_gz and not checking to see if the group file exists. This is problematic at least for the case of preupgrade where we download things using the F8 version of yum (3.2.8) which doesn't know about group_gz and thus doesn't fetch it. So then we get into anaconda and it goes to look at comps and needs comps.xml.gz which isn't there. So we should probably make the group_gz handling a bit smarter than it currently is. Alternately, we could hack preupgrade to retrieve the groups_gz metadata file. Looking to see how well or not that'll work
Something like === modified file 'preupgrade/__init__.py' --- preupgrade/__init__.py 2008-03-27 15:05:51 +0000 +++ preupgrade/__init__.py 2008-03-27 17:26:00 +0000 @@ -337,6 +337,13 @@ # FIXME This screws up preupgrading to rawhide. Gar. if self.comps.compscount == 0: raise PUError, "Cannot retrieve group lists from any repository" + # also try to get the gzipped comps file if it's there so that + # anaconda doesn't have to later. this is kind of ugly (#439232) + for r in self.repos.listGroupsEnabled(): + try: + r.retrieveMD('group_gz') + except: + pass # update all self.update() for preupgrade at least seems to work around the problem and then we can revisit and have yum do something a little bit nicer in the future.
I think it's a really bad idea to make the groups/groups_gz "smarter" ... it basically means (best case) we'll have to call os.path.exists() to see if the groups file exists. Those stat() calls are just going to slow yum down, for this one Fed-8 to Fed-9 pre-upgrade. We didn't do this for the primary to primary_db change, and I think we should treat this as the same.
Also note that the above patch doesn't fix much more than pre-upgrade ... as anything using an mdpolicy which includes group will still need to download a new group file (which includes PK -- so almost everyone). A similar fix for pre-upgrade would be to delete the groups_gz line from the repomd.xml, if the groups file exists on disk. It's mostly the same hack, but it doesn't hurt us long term.
two options: - we can modify the repo check to look for it - we can modify the _get_groups to look for it and see if it is right I'm inclined to think that what jeremy did to fix preupgrade is just fine b/c this is really the only place we're going to run into this.
closing, unless someone would like a different 'fix'