yum groups (comps.xml) support

[Rehan Khan]

Imported: http://tracker.labix.org/issue379

Reason: Patch Review

further details: https://blueprints.launchpad.net/smart/+spec/bug-reporting-migration

msg1335 (view) Author: afb Date: 2008-06-14.20:00:10

I made the necessary patches/additions to smart, so that it will read the
"group" entry from the repomd.xml and create virtual packages accordingly.

[netmask (netmask)]

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.

[Anders F Björklund (afb)]

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.

[Anders F Björklund (afb)]

These "groups" are called "selections" in SUSE/YaST

http://en.opensuse.org/Libzypp/Metadata/YaST/selection

[Anders F Björklund (afb)]

Test case updated to fetch "group" with the rest of the files
http://bazaar.launchpad.net/~afb/smart/groups/revision/823

[Anders F Björklund (afb)]

openSUSE "selections" have moved into "patterns" now:
http://en.opensuse.org/Libzypp/Metadata/YaST/pattern
http://en.opensuse.org/Patterns
Might eventually be translated into yum-compatible comps

[Anders F Björklund (afb)]

Hack for yast2 patterns added in r826

http://bazaar.launchpad.net/~afb/smart/groups/revision/826

[Anders F Björklund (afb)]

Also a new XML-based format for <pattern>, similar to <comps>:
http://en.opensuse.org/Libzypp/Metadata/repomd/patterns
http://en.opensuse.org/Build_Service/Tutorial#Create_Patterns
Chances are that openSUSE will eventually provide both formats.

[Gustavo Niemeyer (niemeyer)]

[1]

+ def excludeDependency(self, group, req):
+ if group == "base" and req == "mcelog":
+ return True
+ if group == "base" and req == "openCryptoki":
+ return True
+ if group == "base" and req == "prctl":
+ return True

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.

[Anders F Björklund (afb)]

Thanks for feedback, typically I just merged the changes in :-)

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...

But there were some concerns raised when the same concept
was introduced as "Collections" in PackageKit, based on this:
http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/
(the Smart backend mapped into the suggested implementation)

One alternative would to keep them separate, like YumEx does ?

[Anders F Björklund (afb)]

Here is the original suggestion of the feature and following discussion:
http://lists.labix.org/pipermail/smart-labix.org/2008-June/003551.html

[Anders F Björklund (afb)]

implementing comps as fake metapackages is probably out

[Anders F Björklund (afb)]

RPM Groups in Yum Extender

[Anders F Björklund (afb)]

Yum Comps in Yum Extender

[Anders F Björklund (afb)]

Apparently these comps/patterns are called "tasks" in Debian parlance, see tasksel.

[Anders F Björklund (afb)]

http://packages.ubuntu.com/search?keywords=tasksel-data&exact=1