rpm.groups - Libraries/Ruby

[Jeff Johnson]

On Jun 24, 2010, at 9:42 AM, Bartosz Taudul wrote:

> 2010/6/24 Jeff Johnson <n3npq at mac.com>:
>>> Why do we care about RPM groups?
>> What else would we discuss if RPMTAG_GROUP did not exist?
> I was referring to the general shit state of the group hierarchy in
> PLD. Basically 90% of the stuff is in Applications or
> X11/Applications, which makes the groups completly useless. There was
> some movement to make them more useful, but that was in 2004 and
> hadn't been talked about since then.
> 
> New group hierarchy proposition can be found at
> http://cvs.pld-linux.org/cgi-bin/cvsweb/PLD-doc/nowe-grupy?rev=HEAD.

This tree is as good as any other I've seen, certainly far far
better than synaptic/aptitude choices.

Have you considered:

Setting up a process to map specific packages into your taxonomy

    Something like a de.licio.us tagging framework to do the mapping
    subjectively with "community" (whatever that means) involvement
    would be one relatively painless process. Any "voting" metric
    (with all the usual voting "fraud" control issues) would work
    as well as de.licio.us

    The other approach used in debtags is to attempt a RDF semantic
    abstraction in order to truly (and "objectively") hammer out
    a usable taxonomy. Its "objectively" that is admirable (and
    interesting to me wrto RPMTAG_GROUP), all the other issues of
    RDF and smantic and classification and ... that are part of the
    methodolgy make my head hurt *a lot*.

Setting up representations of the tree markup in JSON/XML/YAML/HTML/DocBook/...

    The package taxonomy that easily and automagically transforms to the largest
    number of output usage cases is going to "win" in the end. Its not
    just installers that need to present "package" data in useful forms.

And -- if you show me some reasonable markup for your Group: hierarchical tree --
I'll happily patch up RPM to use your markup rather than specspo with
    rpm -qa --qf '%{GROUP}\n'
The patch for other markup isn't anywhere near as hard as getting "consensus" regarding
how a package hierarchical namespace SHOULD look.

If your markup includes some additional means for general "attribute"
tagging of packages, all the better. I have several usage cases in RPM
that are blocked solely by lack of "consensus" on how "attributes"
should be attached to packages (the RPMTAG_COLLECTION patch on
<rpm-maint at rpm.org> is just one of many usage cases).

hth

73 de Jeff