[Revisor-users] Better handling of comps.xml was: Some questions on comps.xml and kcikstart file

[Alexander Todorov]

Moving to revisor-devel-list.

Thread started here:
http://lists.fedoraunity.org/pipermail/revisor-users/2007-November/000517.html


Bernd Hentig wrote:
>>> Here is a quick and simple idea. It probably needs some bug fixing:
>>> 1) During RPM download phase generate a list of available packages. This 
>>> is what will end up on the final media and ideally dependencies are 
>>> satisfies (unless something goes wrong)
>>>
>>> 2) Merge comps.xml files found in all repositories as it is now.
>>> 3) For each <group> tag inspect the <packagelist> and <packagereq> tags.
>>> If the listed package is not in the list of downloaded packages then 
>>> remove it from XML.
>>>     
> What will happen to packages in a repo that are not listed in any comps.xml?

I am working on that as well. The most simple idea is the following:
For all packages selected for installation, that are not already in 
comps.xml add the package in a separate group/category named
"Additional packages". Then append this to the comps.xml
Mark all packages as "default" (since you select them to build the media 
you will probably want to install them as well).

While not perfect this is a somewhat acceptable solution.

> I.e. the packages from the former "extras" repo do not have an entry in
> any comps.xml AFAIK,
> so they will usually not be selectable in any category.
> But all RPMs come with their own - internal - field "Group", shouldn't
> this be used instead?
> BTW, what is the normal purpose of the RPM "Group" field, if it has no
> relation to the comps.xml?

Please take a look at anaconda-devel-list and the preceding thread:
https://www.redhat.com/archives/anaconda-devel-list/2007-November/msg00107.html

Based on the discussion on anaconda-devel-list I would say that the 
Group: rpm tag can be used to generate a comps.xml for any 3rd 
party/personal repository. However I don't think such functionality 
should be incorporated in Revisor. Better leave it as a separate tool 
and let people easily create a comps.xml skeleton and only include in 
Revisor the above idea.
This will make a good point separating the code and not overloading 
Revisor with extra functionality. If one doesn't like the "Additional 
packages" group, then use a tool and create/customize your own comps.xml 
file.

Greetings,
Alexander.