Red Hat Bugzilla – Bug 439232
Always prefers group_gz if in repodata
Last modified: 2014-01-21 18:02:06 EST
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
=== 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():
# update all
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.
- 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'