Bug 439232

Summary: Always prefers group_gz if in repodata
Product: [Fedora] Fedora Reporter: Jeremy Katz <katzj>
Component: yumAssignee: Seth Vidal <skvidal>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: ffesti, james.antill, katzj, pmatilai, tim.lauridsen, wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-08 05:51:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jeremy Katz 2008-03-27 16:54:12 UTC
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

Comment 1 Jeremy Katz 2008-03-27 17:36:15 UTC
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.

Comment 2 James Antill 2008-03-27 17:44:38 UTC
 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.


Comment 3 James Antill 2008-03-27 17:58:02 UTC
 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.


Comment 4 Seth Vidal 2008-04-04 01:49:42 UTC
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.



Comment 5 Seth Vidal 2008-04-08 05:51:18 UTC
closing, unless someone would like a different 'fix'