== Summary ==
Remove the Group: tag from over 9000 source packages.
== Owner ==
* Name: Jason Tibbitts (tibbs)
* Email: tibbs(a)math.uh.edu
== 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
* 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#Tags_and_Sections|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
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
== 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
* 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 [https://pagure.io/releng/issue/7627
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.
Fedora Program Manager