As far I know, a tool by name revisor should do what you are suggesting as well as some more things. But, revisor reads from an existing comps file and writes it out into another as per user's selection. It doesnot give support for addiing/modifying/deleting categories and groups in the GUI. Myself and one of my friends are interested in precisely the same. We are modifying revisor's python scripts for doing the same.
With Regards, Prasad H. L.
----- Original Message ---- From: Alexander Todorov atodorov@redhat.com To: Discussion of Development and Customization of the Red Hat Linux Installer anaconda-devel-list@redhat.com Sent: Thursday, November 22, 2007 3:53:41 PM Subject: Generating comps.xml
Hello, I've found this quite old document explaining the comps.xml structure: http://rhlinux.redhat.com/anaconda/comps.html
It mentions the getfullcomps.py script to generate the package sections
of comps.xml. My comps-extras package contains only images and no helper scripts.
Is comps.xml produced manually nowadays? Is there any tool to automate comps.xml generation? If not is anybody interested in implementing such
a tool? Is there a need for one?
Thanks, Alexander.
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Prasad H.L. wrote:
As far I know, a tool by name revisor should do what you are suggesting as well as some more things. But, revisor reads from an existing comps file and writes it out into another as per user's selection. It doesnot give support for addiing/modifying/deleting categories and groups in the GUI. Myself and one of my friends are interested in precisely the same. We are modifying revisor's python scripts for doing the same.
Yes, I'm aware of Revisor and what it does. Please see here: http://lists.fedoraunity.org/pipermail/revisor-users/2007-November/000518.ht...
What I am ultimately looking for is a tool that will generate comps.xml skeleton based on directory containing RPM packages. AFAIK no such tool exists.
As it's been long time since comps.xml exist and no automation tool is used I wonder why. Is automation bringing a lot more issues that take more time to solve that hand crafting the comps or simply nobody was interested in writing a tool?
Greetings, Alexander.
On Thu, Nov 22, 2007 at 11:44:32AM +0100, Alexander Todorov wrote:
What I am ultimately looking for is a tool that will generate comps.xml skeleton based on directory containing RPM packages. AFAIK no such tool exists.
But what groups and categories you want to idenify, and what packages you want to be included in a group as default, mandatory, and optional can not be automated without extra information.
Jos Vos wrote:
On Thu, Nov 22, 2007 at 11:44:32AM +0100, Alexander Todorov wrote:
What I am ultimately looking for is a tool that will generate comps.xml skeleton based on directory containing RPM packages. AFAIK no such tool exists.
But what groups and categories you want to idenify, and what packages you want to be included in a group as default, mandatory, and optional can not be automated without extra information.
Group information can be extracted from the RPM package: e.g. Group : System Environment/Base may result in system-environment group with base subgroup or something like that. This group includes the packages that are tagged with that group name in the .spec file.
You are right that default, mandatory and optional is hardly automated. For that one needs a criteria of some kind (that is probably missing in the RPM file).
Still that can be useful for 3rd party/private repositories especially when remixing Fedora. As of now I think there is no way to get 3rd party packages visible in Anaconda GUI other than comps.xml or you need a ks.cfg file to install these packages.
I am not at all sure if auto generation tool will help and that's why I need more opinions.
Greetings, Alexander.
On Thu, Nov 22, 2007 at 12:07:51PM +0100, Alexander Todorov wrote:
Group information can be extracted from the RPM package: e.g. Group : System Environment/Base may result in system-environment group with base subgroup or something like that. This group includes the packages that are tagged with that group name in the .spec file.
This assumes there is a one-to-one mapping between used RPM group names and comps groups. AFAIK this is currently not the case. It could be done that way, as the RPM group tag is not used for anything else at this moment (in the past anaconda used it for showing a tree structure, IIRC).
You are right that default, mandatory and optional is hardly automated. For that one needs a criteria of some kind (that is probably missing in the RPM file).
As the RPM group tag is just a string, you could probably even include it there, like with "Group: base(optional)" or "Group: kde-desktop(mandatory)".
Jos Vos wrote:
As the RPM group tag is just a string, you could probably even include it there, like with "Group: base(optional)" or "Group: kde-desktop(mandatory)".
That would interfere with best practices and the group list found at: /usr/share/doc/rpm-$version/GROUPS
On Thu, 22 Nov 2007 13:02:31 +0100 Alexander Todorov atodorov@redhat.com wrote:
That would interfere with best practices and the group list found at: /usr/share/doc/rpm-$version/GROUPS
The Fedora best practices state that you have to have a Group: tag in your spec, because rpm will barf it it isn't there. However we largely don't care what's there as it's not used by our standard tool set. We're working to a point where Group goes away completely, as grouping of packages is really an outside the package issue, so that people can redefine groupings without rebuilding packages.
On Thu, 2007-11-22 at 12:24 +0100, Jos Vos wrote:
On Thu, Nov 22, 2007 at 12:07:51PM +0100, Alexander Todorov wrote:
You are right that default, mandatory and optional is hardly automated. For that one needs a criteria of some kind (that is probably missing in the RPM file).
As the RPM group tag is just a string, you could probably even include it there, like with "Group: base(optional)" or "Group: kde-desktop(mandatory)".
But doing this misses part of the point, though. By putting the grouping information _outside_ of the package, you can easily change it without having to rebuild the package.
And yes, you could change it even if you were doing like this, but I think it would lead to even more confusion than there is today :)
Honestly, I'd rather have rpm not require the group tag and just drop specifying it from spec files
Jeremy
Jeremy Katz wrote:
Honestly, I'd rather have rpm not require the group tag and just drop specifying it from spec files
I agree with that; if I were building my own distro (let's pretend it's ClarkConnect) from Fedora or RHEL, I'd prefer to decide for myself what the groups are called and how they relate to everything.
Having the groups tag just gives me something else to assess, to decide how or whether I should change.
What would be useful is a classification system. Everything that lands in /{bin,sbin,lib} is essential because the system won't work at all without it and nobody really wants to omit it, and maybe a little more might be fhs-essential.
This would be pretty much the absolute minimum required for an install that's capable of being booted and extended. It would be feasible, when creating install media, to preinstall (most of)[1] this, and package it into a tarball.
[1] If there might be some package selection that must be deferred to installation time (I'm thinking kernel maybe, but presumably the kernel being used to install could be packaged) then maybe that wouldn't be preinstalled.
anaconda-devel@lists.fedoraproject.org
-
Alexander Todorov -
Jeremy Katz -
Jesse Keating -
John Summerfield -
Jos Vos -
Prasad H.L.