rpm.groups - Libraries/Ruby

[Jeff Johnson]

On Jun 24, 2010, at 9:42 AM, Bartosz Taudul wrote:

> 2010/6/24 Jeff Johnson <n3npq at 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-maint at 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