<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Richard Hughes wrote: <blockquote cite="mid:1195422825.2228.14.camel@hughsie-laptop" type="cite"> <pre wrap="">On Sun, 2007-11-18 at 16:24 -0500, Matthias Clasen wrote: </pre> <blockquote type="cite"> <pre wrap="">Ok, I figured this one out. I had fedora-development configured to use the static koji repo, which doesn't have meaningful comps, thus there are no groups in the metadata. pirut handles this situation a bit better, it only shows groups when they are available in the repository. </pre> </blockquote> <pre wrap=""> Yum guys, can we do the same here, and not return SearchGroup when we have no comps available please. Thanks. Richard. _______________________________________________ PackageKit mailing list <a class="moz-txt-link-abbreviated" href="mailto:PackageKit@lists.freedesktop.org">PackageKit@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/packagekit">http://lists.freedesktop.org/mailman/listinfo/packagekit</a> </pre> </blockquote> Currently all packages will be in GROUP_OTHER if no comps data is available in the repo. It is a difficult case,  because there is can be comps.xml with group infomation for each repo, but it is not an error if one repo is missing a comps.xml, so it is a bad idea to raise an error. The backend should not return any groups other than GROUP_OTHER, if no comps metadata exist. I think the problem is that we have hardcoded the available groups in the pk-backend-yum.c, maybe it is an idea to add a get-groups.py helper to return the available groups in the current active repo setup. Tim </body> </html>