FYI (from a RPMTAG_GROUP discussion on the PLD devel mailing list).
You should recognize the URI's in the message, they were all snipped frpm the thread here on centos-devel.
The comments are purely mine, and intended as analysis, no intent whatsoever to offend anyone.
The engineering problem of enabling luser choice is in fact very hard to solve when based on contributed FL/OSS efforts.
73 de Jeff
Begin forwarded message:
From: Jeff Johnson n3npq@mac.com Date: June 24, 2010 11:43:11 AM EDT To: "PLD: Developers list (English)" pld-devel-en@lists.pld-linux.org Subject: Re: rpm.groups - Libraries/Ruby
On Jun 24, 2010, at 11:22 AM, Bartosz Taudul wrote:
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.
It was based on sourceforge trove software map.
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.
Translation: noone would do it. Not worth the effort.
If you're saying Noone has time for bookmarking at http://de.licio.us any more. I absolutely agree.
(aside) In fact bookmarking (and Google keyword searches) Just Don't Work Well, but that's a whole different and quite complex discussion. I kinda like de.licio.us because I can track through a bookmark tag to see what _ELSE_ a person interested enough to add a de.licio.us bookmark that blipped my radar might be interested in. I can't do that with Google keyword searches.
But de.licio.us (and more generally Ajax) are a pathway to automated collection of "voting" metrics for "attributes" attached to "packages" indepnedently (and persistently) after a package has been built. The ultimate design flaw with RPMTAG_GROUP (and other tags in RPM metadata) is that static content delivery isn't very useful in 2010, the "process" to embed tags in packaging reliably is just too cumbersome these days.
The code for de.licio.us (and Ajax and REST-ful in general) is there for the stealing is all I meant to point out.
But go look at any site that is advertising RPM "packages". Here's are several URL's (from a thread on centos-devel mailing list) I had to visit this week:
http://packages.debian.org/lenny/php5 http://www.freshports.org/
All of those "package" presentations are ugly, useless, uninformative and otherwise as pointless as RPMTAG_GROUP is in RPM installers.
This URL I particularly have issue with (not with the site per se) http://pkg.org.ua/ Note the organization using "vendor" as a toplevel "attribute" for "package" choosing.
If "vendor" is the only "attribute" that is presented to lusers, well, FL/OSS software is just doomed.
And it wouldn't be that hard to change the "package" presentation using, say, a more reasonable and intelligent hierarchical tree like what you pointed me to.
hth
73 de Jeff
-
Jeff Johnson