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 at mac.com> > Date: June 24, 2010 11:43:11 AM EDT > To: "PLD: Developers list (English)" <pld-devel-en at 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