yum groups (comps.xml) support

Bug #244969 reported by Rehan Khan on 2008-07-02
Affects Status Importance Assigned to Milestone
Smart Package Manager

Bug Description

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.

Related branches

Rehan Khan (rasker) wrote :
netmask (netmask) on 2008-07-03
Changed in smart:
assignee: nobody → afb
status: New → In Progress
Changed in smart:
importance: Undecided → Medium
status: In Progress → New
netmask (netmask) wrote :

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) wrote :

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) wrote :

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


Changed in smart:
status: New → In Progress
Anders F Björklund (afb) wrote :

Test case updated to fetch "group" with the rest of the files

Anders F Björklund (afb) wrote :

openSUSE "selections" have moved into "patterns" now:
Might eventually be translated into yum-compatible comps

Anders F Björklund (afb) wrote :
Anders F Björklund (afb) wrote :

Also a new XML-based format for <pattern>, similar to <comps>:
Chances are that openSUSE will eventually provide both formats.

Changed in smart:
milestone: none → 1.2
Gustavo Niemeyer (niemeyer) wrote :


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


+ __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__


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

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) wrote :

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:
(the Smart backend mapped into the suggested implementation)

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

Anders F Björklund (afb) wrote :

Here is the original suggestion of the feature and following discussion:

Anders F Björklund (afb) wrote :

implementing comps as fake metapackages is probably out

Changed in smart:
assignee: afb → nobody
milestone: 1.2 → none
Anders F Björklund (afb) wrote :

RPM Groups in Yum Extender

Anders F Björklund (afb) wrote :

Yum Comps in Yum Extender

Changed in smart:
milestone: none → 1.4
Anders F Björklund (afb) wrote :

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

Changed in smart:
milestone: 1.4 → none
Changed in smart:
status: In Progress → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers