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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
