Bug 439232 - Always prefers group_gz if in repodata
Always prefers group_gz if in repodata
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-27 12:54 EDT by Jeremy Katz
Modified: 2014-01-21 18:02 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-08 01:51:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeremy Katz 2008-03-27 12:54:12 EDT
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 13:36:15 EDT
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 13:44:38 EDT
 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 13:58:02 EDT
 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-03 21:49:42 EDT
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 01:51:18 EDT
closing, unless someone would like a different 'fix'

Note You need to log in before you can comment on or make changes to this bug.