New Comps Groups

Toshio Kuratomi a.badger at gmail.com
Sat Dec 2 16:26:04 UTC 2006


On Sat, 2006-12-02 at 01:20 +0100, Christian Iseli wrote:
> Trying to step back a bit here...
> 
> Things I'd like to do from a user point of view:
> - see what apps are available for performing some tasks, e.g. create
>   video DVD, develop and test that new python package, ...
> - have an easy way to select the packages I find useful and install them
> 
> Things I'd like to do from a packager point of view:
> - attach some grouping info to my packages, e.g., this package is a
>   bioinformatics tool, it is meant to run in a KDE environment, ...
> - be able to tell e.g. fellow bioinformaticians: just do a
>   "yum groupinstall bioinformatic-tools"
>   and you will be good to go
> - not have to enter redundant info into many different files
> 
> Things I suspect a release creator would like to do:
> - define a set of packages that should get installed when the user
>   chooses a certain type of install, e.g.:
>   o KDE desktop
>   o GNOME desktop
>   o web server
>   o barebone minimal
> 
> Things I'd like to do from a QA point of view:
> - make sure all packages get consciously assigned to the proper
>   group(s)
> - easily verify the correctness of the comps.xml file
> 

These are great lists!  I've started a page on the wiki with ideas from
this thread:
http://www.fedoraproject.org/wiki/Extras/SIGs/Comps/PackageGroupEnhancements

It's just a quick summary so feel free to pile on with enhancements,
additions, and corrections.

> 
> The current state of things is that the Group tag in spec files is not
> flexible enough, and its location within the spec file not appropriate
> for many of the above goals.
> 
> The current state of things is that the comps.xml file is the only
> mean we have right now to deal with the above goals.  Maybe it is not
> well suited either to fulfill all of them, but that's all we have
> ATM...  It is used by anaconda, pungi, yum, pirut, ...
> 
> What I'm wondering is whether:
> - adding some useful, task oriented, groups to comps might make for a
>   better user experience
Yes.  I think which groups to add depend on the use case (installer vs
repoview vs...)  Additionally, Nicolas's separation of "groups" from
"categories" looks like a good thing for your list of goals.

> - maybe extending the comps file, as proposed by Nicolas, is enough
>   until a better solution is defined and implemented
I think Nicolas's proposal is more of a replacement than an extension.
Currently, comps is a list of groups which contain packages and
attributes describing the package's relation to the group.  Nicolas's
proposal separates packages and groups with an intermediate layer of
categories.  An individual collection-policy is responsible for
establishing the association.

> - having hidden "only used in support of another package" packages in
>   comps is really that bad
I don't think this is bad as a short term solution.  I think Jeremy
disagrees :-)  We've had to deal with the limitations of the RPM Group
tag for years, though.  Continuing to do so might not be all bad.

> - comps might completely disappear once the package database is up and
>   running
IMHO, shipping the information around in an xml format makes sense as
there's a multitude of applications that want to use it.  That format
may or may not be the current comps.xml, though.  As a future
enhancement it's possible we could edit the information in the packageDB
and the information then be made available via scheduled regeneration or
by request through a URL.  Please note, though, that the current
packageDB schema does not have groups or categories and it operates on
base packages (mapping to SRPMS) while comps deals in built packages.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20061202/82655031/attachment.sig>


More information about the fedora-extras-list mailing list