Remove the Group: Tag From All Packages
Summary
Remove the Group: tag from over 9000 source packages.
Owner
- Name: Jason Tibbitts
- Email: tibbs@math.uh.edu
- Release notes owner:
Current status
- Targeted release: Fedora 30
- Last updated: 2018-08-22
- Tracker bug: <will be assigned by the Wrangler>
Detailed Description
I will remove the Group: tag from all specfiles in Fedora dist-git which still have it, verify that the result is syntactically correct, then commit and push the change. Since this is a relatively minor changeI am not planning to bump Release: or add %changelog entries, but I do that if it is deemed necessary.
I am proposing this as an official change instead of just doing it (as with other low risk packaging cleanups) because:
- It would be by far the largest mass package change we would ever have attempted.
- It does technically cause a visible change in the resulting package. If queried, rpm will show the group as "Unspecified" for every binary package in the distribution instead of just the majority of them. It is theoretically possible that someone could have a tool which uses this information, although that tool most already be mostly useless.
- People would yell at me even more loudly if I posted the full 9000+ package and maintainer listing.
Since this changes many, many packages and has small but nonzero end user visibility I am filing this as a system-wide change.
Benefit to Fedora
9420 source packages (43% of the total count) come closer to compliance with Fedora's packaging guidelines. The Group: tag has been in a "should not use" state since March of 2017.
More useless cruft is removed from specfiles. This provides a slight benefit to ease of maintenance and eliminates yet another bizarre historical relic which confuses new packagers. Cargo cult behavior is rampant and removing the cruft in one go will be another step towards having system-wide clean specfiles.
The Group: tag is not required in any live Fedora or EPEL release. RHEL5 did need it, but EPEL5 did not as it was supplied automatically via magic in the epel-rpm-macros package. The Packaging Guidelines have indicated that the Group: tag should not be used since March of 2017.
The tag is not used by Fedora currently; the concept was replaced long ago by comps which permits a far more flexible classification of packages. dnf has a "group" subcommand but this operates on comps groups, not anything defined by the Group: tag. dnf does not display information from Group: tag. If a package does include a Group: tag, a direct rpm query will display it but otherwise will show "Unspecified".
There was never any strong standard for the contents of the Group: tag. Older versions of rpm (still present in RHEL7 but not in any live Fedora release) contained a documentation file named GROUPS with a list and rpmlint would check this, but it was never strongly adhered to. The current package set has some quality examples like a Group tag containing the string "Group:" and one containing only "evelopment/Languages". It seems relatively obvious that nobody is paying attention or making use of that data.
Among the tags which are at least in the recommended set which rpm used to have, most do not convey particularly useful information. Of the Group: tags which remain, 5438 contain "Development/Libraries", 1871 have "System Environment/Libraries" and 1346 are "Development/Languages".
Scope
- Proposal owners: Whip up a quick script, test it well to ensure that it doesn't have unintended side effects, and handle outliers or special cases manually. Then wait a few hours to push commits to 9000+ repositories.
- Other developers: Nothing besides dealing with any commit emails they receive.
- Release engineering: There should be no releng involvement. There is no real need for any packages to be rebuilt. If there is an F30 rebuild scheduled, it would be advantageous for this change to be made before that happens. I filed [1] in any case.
- List of deliverables: There should be no change to deliverables besides the fact that the packages no longer have Group: tags.
- Policies and guidelines: This is implementing a requirement of the current packaging guidelines. The specific change mandating this happened in March of 2017.
- Trademark approval: N/A (not needed for this Change)
Upgrade/compatibility impact
There is no effect on upgrades. Packagers have always been free to remove Group: tags, even within a stable release. This will simply result in the rest of them going away.
How To Test
There is not much to test. The change is simple and so if done with a modicum of care it will not cause syntax errors in the packages. Testers and maintainers can of course do local or koji builds after the changes have been pushed to ensure that there are no problems, and rpm -qip run on the resulting binary packages should only show Group: tags of "Unspecified".
User Experience
There should be no change to the end user experience unless there is an expectation that the Group: tags of the changed packages will show something other than "Unspecified".
Dependencies
There are no dependencies.
Contingency Plan
If there is some issue, it is simply possible to do nothing, or to change only a subset of packages.
If changes are committed and it turns out that there is some unforeseen negative effect, the changes can simply be reverted.
- Contingency mechanism: Either do nothing, or revert the changes in the unlikely event that they cause issues.
* Contingency deadline: Before the mass rebuild.
- Blocks release? No
- Blocks product? N/A
Documentation
The process is generally obvious and should not require much in the way of involvement of anyone else.
Release Notes
There should be no need to note this change in any release notes, as it is merely the completion of a change which has been ongoing since the time of Fedora 12.