On Wed, Jan 18, 2012 at 2:30 PM, Bill Nottingham <notting@xxxxxxxxxx> wrote: > 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? Great idea, I would also love to see a clear out of the packages that aren't core/part of particular categories. MTAs in minimal would be one that comes to mind but there's lots of other examples. Peter -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
