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 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 - maybe extending the comps file, as proposed by Nicolas, is enough until a better solution is defined and implemented - having hidden "only used in support of another package" packages in comps is really that bad - comps might completely disappear once the package database is up and running C -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
