On Jun 24, 2010, at 9:42 AM, Bartosz Taudul wrote: > 2010/6/24 Jeff Johnson <[email protected]>: >>> 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 <[email protected]> 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 [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
