Following up with notes from FUDCon. Bill Nottingham (notting@xxxxxxxxxx) said: > == Distribution construction == > > For this, we will continue to use groups in comps. > > PRO: > - Don't have to change any distribution tools > - Don't have to change kickstarts > > CON that can be fixed: > - Doesn't allow for tracking what groups a user has installed > - Doesn't allow for adjusting installations to new groups > - The 'group removal' operation does not behave in a way users expect > > By using something like what's suggested in: > http://lists.baseurl.org/pipermail/yum-devel/2010-December/007740.html > > we can make groups persistent objects in yum, such that it's stored what > groups the user has installed, what packages are in those groups, and so on. This was discussed at FUDCon, and there was general agreement that this is the way to go. However, there are a couple of implementation notes here: 1) If we are both reorganizing groups (splitting, renaming, etc.) and making them first-class objects in yum, we need to do both *at the same time*. 2) The anaconda UI change is not landing in F-17. If what we're doing affects anaconda package selection deeply, we need to wait until F-18. I'm going to investigate how much of this can be done without significant anaconda changes; if it can't be done well, then we'll wait until F-18. > == Package categorization for browsing == > > In PackageKit parlance, these are 'collections'. Here, I have a few proposals. > > 1) Continue to use groups in comps > > PRO: > - Don't have to change any package tools > CON: > - Requires editing to list a package > - Need to separate them from groups used for distribution construction > > 2) Give packages in tags. Sort packages for choosing by them > > Options would be: > - as a header in the RPM package, extracted into metadata > - as a entry in the package database, extracted into some useable form > - as part of the pkgtags yum metadata > > PRO: > - Decentralized. Allows packages to organize themselves > CON: > - Requires touching every package (if it's set in the package) > - Requires RPM changes (if it's set in the package) > - Requires a mechanism to generate metadata > - Requires modifying packaging tools (mostly PackageKit) to support this > metadata > - Decentralized. Any package can mess up the display and organization by > using a garbage tag. > > 3) Invent some similar curated listing, similar to groups in comps, but not > in comps > > CON: > - ... why bother, other than to just move the data? During the talk at FUDCon there was a lot of discussion about how to do tags for packages that would be set by the maintainer, that could be used in addition to the tags in the database set by the Fedora Tagger. One option was tags in a file in the package git repo, that could then be pulled into the metadata; the pros and cons of this were discussed. Later it was brought up that it may just be simpler to create a second file of metadata, similar to the comps file, that just contains lists of categorized packages. (i.e., #3 above.) Opinions? Bill -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
