Package categorization and distribution construction

[Peter Robinson]

On Wed, Jan 18, 2012 at 2:30 PM, Bill Nottingham <notting at redhat.com> wrote:
> Following up with notes from FUDCon.
>
> Bill Nottingham (notting at redhat.com) 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