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 ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.groups - Libraries/Ruby
>> 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. wolf ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.groups - Libraries/Ruby
On Jun 24, 2010, at 9:42 AM, Bartosz Taudul wrote: > 2010/6/24 Jeff Johnson : >>> 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 is just one of many usage cases). hth 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.groups - Libraries/Ruby
On Jun 24, 2010, at 10:11 AM, Artur Wroblewski wrote: > 2010/6/24 Jeff Johnson : >> >> On Jun 24, 2010, at 9:36 AM, Paweł Zuzelski wrote: >> >>> On Thu, 24 Jun 2010, Jeff Johnson wrote: > [...] Did Poland do well in South Africa? >>> >>> Not so bad, we have not lost any game yet. >>> >> >> Lots of ties eh? ;-) > > No ties, it is just impossible for us to loose. :) > Send the Polish team down to the Gulf of Mexico when they're through playing around with the football in South Africa please. I hear there's an oily mess to clean up ... 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.groups - Libraries/Ruby
2010/6/24 Jeff Johnson : > > On Jun 24, 2010, at 9:36 AM, Paweł Zuzelski wrote: > >> On Thu, 24 Jun 2010, Jeff Johnson wrote: [...] >>> Did Poland do well in South Africa? >> >> Not so bad, we have not lost any game yet. >> > > Lots of ties eh? ;-) No ties, it is just impossible for us to loose. :) Best regards, w ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.groups - Libraries/Ruby
On Jun 24, 2010, at 9:42 AM, Bartosz Taudul wrote: > 2010/6/24 Jeff Johnson : >>> 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. > Jeff, it would be interesting to hear what do you think about > replacement of groups with tags, as that might make more sense. Well all I've ever been able to figure (the proposals for Newer! Better! Bestest! Group: values come out approx. monthly regular as clockwork) is to get RPMTAG_GROUP out of *.rpm metadata entirely (which was achieved years ago with specspo just noone uses). Even if you stabilize the msgid's like "Library/Ruby", you've got the msgstr's to deal with for i18n encoding display purposes. No way that all of that process can ever succeed if/when compiled into *.rpm metadata. As soon as you achieve anything, the entire "process" restarts itself again and again and again ... But detaching RPMTAG_GROUP from *.rpm packages is quite doable (see specspo for "doable" even if you think spescpo is crap -- specspo is crap imho), in order to support multiple hierarchies with well defined markup (hopefully _NOT_ PO as in specspo), with encodings and ... > Prototype graphical package manager which sorts packages by groups can > be downloaded from http://team.pld-linux.org/~wolf/pacman/, but it's > not all that useful. ... per-application "sorts" and criteria should be attempted. (aside re "useful") Typically RPMTAG_GROUP is implicitly used as a hierarchical "attribute" name space. The "hierarchical" permits sorting, and the "attribute" permits tagging of subsets of a very large universe of "packaging". What's tricky is that the values in the name space aren't reliable. There's _LOTS_ that could be implemented in installers like RPM et al with a "set membership" attribute if the data values in the name space were reliable. For one slightly different, but related to RPMTAG_GROUP as an "attribute" attached to packages, see the recent addition of RPMTAG_COLLECTION on the mailing list (Note: I don't believe the Tresys patchset as posted/adopted will ever work in any version of RPM, but the RPMTAG_COLLECTION attribute framework for "set membership" is savable if the data is populated with methodolgy and discipline.) > Prototype tool for managing package groups can be downloaded from > http://team.pld-linux.org/~wolf/rgmt.7z, but it works only with the > old SPECS/SOURCES structure and will break on some spec files. But, > since it displays the groups from all the spec files, it can show how > much chaos and typos is there, since nobody really cares. > > tl;dr: RPM groups in PLD suck. > GROUPS in RPM suck, that's no PLD fault. 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.groups - Libraries/Ruby
On Jun 24, 2010, at 9:36 AM, Paweł Zuzelski wrote: > On Thu, 24 Jun 2010, Jeff Johnson wrote: >> What else would we discuss if RPMTAG_GROUP did not exist? > > Sorry, I don't get it. > Translation from obscure jbj-speak: RPMTAG_GROUP is utterly broken as a "package" metadata item because there is No One True Taxonomy! Nor can One True Taxonomy be devised manually (but debtag facets are the most interesting approach) >> Did Poland do well in South Africa? > > Not so bad, we have not lost any game yet. > Lots of ties eh? ;-) 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.groups - Libraries/Ruby
2010/6/24 Jeff Johnson : >> 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. Jeff, it would be interesting to hear what do you think about replacement of groups with tags, as that might make more sense. Prototype graphical package manager which sorts packages by groups can be downloaded from http://team.pld-linux.org/~wolf/pacman/, but it's not all that useful. Prototype tool for managing package groups can be downloaded from http://team.pld-linux.org/~wolf/rgmt.7z, but it works only with the old SPECS/SOURCES structure and will break on some spec files. But, since it displays the groups from all the spec files, it can show how much chaos and typos is there, since nobody really cares. tl;dr: RPM groups in PLD suck. wolf ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.groups - Libraries/Ruby
On Thu, 24 Jun 2010, Jeff Johnson wrote: > What else would we discuss if RPMTAG_GROUP did not exist? Sorry, I don't get it. > Did Poland do well in South Africa? Not so bad, we have not lost any game yet. -- Regards, Paweł Zuzelski ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.groups - Libraries/Ruby
On Jun 24, 2010, at 7:31 AM, Bartosz Taudul wrote: > 2010/6/24 Paweł Zuzelski : >> Any comments? > Why do we care about RPM groups? > What else would we discuss if RPMTAG_GROUP did not exist? Did Poland do well in South Africa? 73 de Jeff ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm.groups - Libraries/Ruby
2010/6/24 Paweł Zuzelski : > Any comments? Why do we care about RPM groups? wolf ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
rpm.groups - Libraries/Ruby
Proposition: let's add new groups for ruby packages: Libraries/Ruby Development/Languages/Ruby Any comments? -- Regards, Paweł Zuzelski ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en