Bug 458460 - Please add Sugar/Activities to rpm GROUPS list.
Summary: Please add Sugar/Activities to rpm GROUPS list.
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-08-08 16:15 UTC by Robin Norwood
Modified: 2009-11-25 09:07 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-11-25 09:07:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
trivial sugar group patch (280 bytes, patch)
2008-08-08 16:15 UTC, Robin Norwood
no flags Details | Diff

Description Robin Norwood 2008-08-08 16:15:35 UTC
Created attachment 313816 [details]
trivial sugar group patch

According to the packaging guidelines (http://fedoraproject.org/wiki/Packaging/SugarActivityGuidelines), the proper rpm group for sugar activities is 'Sugar/Activities'.  However, rpmlint complains about this group because it isn't in rpm's GROUPS file.  Could you please add this group, on the theory that sugar activities are 'different' enough to require their own group.

Adding this to F-9 as well as devel would be helpful, since a lot of sugar-on-Fedora activity is planned for F-9.

Comment 1 Panu Matilainen 2008-08-15 08:08:58 UTC
Adding would be trivial of course, but... the GROUPS file in upstream rpm tarball has been irrelevant and out of reality for years. Every distro uses their own set of groups, and nothing in rpm even tries to check group "validity" from anywhere.

If rpmlint wants to check for group sanity, I think it'd be more productive to have the "valid groups" listed in some distro-specific location instead, be it within rpmlint or another distro-specific package like fedora-release or such.

Ville, thoughts?

Comment 2 Ville Skyttä 2008-08-21 17:14:06 UTC
rpmlint used to have a built in list of "valid" groups but it was pretty much useless upstream because as Panu said, distros have pretty varying ideas what the valid groups might be - therefore it was changed to a least common denominator there, the GROUPS file shipped with rpm.

The ability to configure the list of valid groups is still there, but on the other hand I'm not personally interested in maintaining such a list (in rpmlint or elsewhere).  And I suppose not many others are either.

Given the above and that the Fedora packaging guidelines do not IIRC really say a thing about the Group tag (except that it's present in spec templates, probably just because it's mandatory in current "GA" rpm releases - the SugarActivityGuidelines does not provide a rationale for their choice either), one logical conclusion would be to drop the check from rpmlint altogether.  But on the other hand, there's some software out there that do group packages based on the group tag so there's still some value in consistent use of them so I'd rather not drop that feature completely.

But if someone wants to spend maintaining a list somewhere and gets some kind of an official blessing/status for that work, I won't object changing rpmlint to use it.  (Cc'ing rpmlint co-maintainers for more thoughts.)

It's of course possible that I'm not aware of something that would make the Group tag more useful in sugar/OLPC context than generally in Fedora, but my WAG would be that it's even less useful there - if that's correct, my recommendation would be to either choose another group for sugar activity packages that rpmlint does not complain about, or simply ignore its warnings on this.  (You can also do that in your own /etc/rpmlint/config or ~/.rpmlintrc, see addFilter() examples in /usr/share/rpmlint/config.)

Comment 3 Panu Matilainen 2009-11-25 09:07:38 UTC
Me thinks its time to close this... the Group tag isn't even required by rpmbuild anymore so there's even less point in updating the group list, and rpmlint allows filtering it out if necessary.


Note You need to log in before you can comment on or make changes to this bug.