On 08/22/2018 01:28 PM, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Remove_Group_Tag > > == Summary == > Remove the Group: tag from over 9000 source packages. > > == Owner == > * Name: Jason Tibbitts (tibbs) > * Email: tibbs@xxxxxxxxxxx > > == 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#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 > "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. > If I run: vim foo.spec on Rawhide, it will create a spec template which includes the Group tag, so this should be updated too. -Tom > * 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] in > any case. > > ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|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. > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/GN2GO5ZYPKIRBJPVXJZZFWXSLUPDXNNZ/
