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
Re: rpm.groups - Libraries/Ruby
2010/6/24 Paweł Zuzelski z...@xatka.net: 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
Re: rpm.groups - Libraries/Ruby
On Jun 24, 2010, at 7:31 AM, Bartosz Taudul wrote: 2010/6/24 Paweł Zuzelski z...@xatka.net: 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
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
2010/6/24 Jeff Johnson n3...@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. 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 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
On Jun 24, 2010, at 9:42 AM, Bartosz Taudul wrote: 2010/6/24 Jeff Johnson n3...@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. 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 rpm-ma...@rm.org 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
2010/6/24 Jeff Johnson n3...@mac.com: 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 10:11 AM, Artur Wroblewski wrote: 2010/6/24 Jeff Johnson n3...@mac.com: 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
On Jun 24, 2010, at 9:42 AM, Bartosz Taudul wrote:
2010/6/24 Jeff Johnson n3...@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-ma...@rpm.org 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
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 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
