Matthew Miller wrote: > Well, or "find plan c and work to make sure it's integrated in future > versions of dnfdragora". That would have to be done BEFORE we drop the comps entries though. > The RPM Group tag is very inflexible — even beyond the "dewey decimal > system" problem where the categories we had weren't very forward-thinking, We don't have to use the historical Red Hat categories. We already mass- removed the old Groups from specfiles, so we can add new ones now. We could use any of: * https://en.opensuse.org/openSUSE:Package_group_guidelines * https://wiki.mageia.org/en/RPM_groups_policy * any other existing category list from another distro, * a new list defined specifically for Fedora. This is purely a policy issue. Software consuming the groups will not care about what the list of groups is. It just needs to make sense to the users. > they don't allow packages to be part of more than one group, That can be seen as a drawback, but also as a feature. We frown upon .desktop files showing up in more than one menu category. The same arguments can be used here. Of course, it can make sense to have an application under two categories (e.g., Amarok both under KDE Applications and under Sound), but there are also arguments for picking one. Overlap can also often be avoided by judicious definition of groups. (E.g., we probably would not have a "KDE Applications" group, the "KDE" or "Plasma" group would only contain the KDE Plasma Desktop Workspace itself.) The current @kde-apps comps group is mainly needed to compose images, but we would not use the RPM Group tags for that anyway. > and depend on the package maintainer rather than on group curation. This one, I would definitely consider a feature! Even now with comps, the policy says that the package maintainer is responsible for adding the package to the comps group. The main reason it is often forgotten is that this is yet another place to touch, outside of the specfile. If we require the tag in the specfile instead, it will be part of the review process, and fedora-review can automatically print an error for missing Group tags (just as there is currently one if Group is missing). For existing packages, we need a mass change just like "Remove Group" was. And the really nice thing is: removed packages can never clutter a group listing because they will just be gone, and their Group tag will be gone along with them. So the current problem that we have obsolete packages in the comps groups would go away completely! Kevin Kofler _______________________________________________ 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
