I see from the patch that the groups are mandatory. IMO this should not be the case, as you cannot have any guarantees that a given repo will have the group information. You need to find a way to either a) make group information optional or b) only fetch this information when required.

The "group" entry in metadata is not mandatory, the patch only complains if the repomd.xml says that it should have a group but it can't be downloaded or verified for some reason. But neither group nor updateinfo are required.

This may be made much more efficient by using a dictionary
with (group, req) keys.

[2]

+ __stateversion__ = Loader.__stateversion__+3

We only have to add to increase the state version number when there
are changes in the code that would make loading code from the cache
crash the application. In these cases, bumping the version ensures
that the cache is discarded. Since this is the first version of
this code, we can start just with:

__stateversion__ = Loader.__stateversion__

[3]

if not pkgpaths[pkg]: pkg.installed = True
continue

Looking at the implementation, I see a few different reasons to
believe that the approach for implementing these features may not
be a good one.

Think a bit about what is going on above. It's saying that if the
loader doesn't provide a path to the package, the package is considered
as installed. Now, conceptually, whatever the format of the package is,
it *must* have a files so that it can be installed, otherwise it's not
really a package. The lack of files indicates a bad error right now.
So looking at the whole implementation, I feel like we're coding this
as a hack, reusing existent concepts in a way they were not intended
to be used.

I definitely would like to introduce support for groups, but I believe
we have to approach package groups as being package groups, and modify
Smart to handle them as such: a concept that doesn't yet exist and
should be designed to be seen and operated as package groups.

I know that comps-as-metapackages is a hack, just seemed
better than the alternative which would be yum groups missing.
Or reimplementing it as "groupinstall" and "groupremove" and
keeping it parallel to all the other (very similar) packages...