On Sun, Sep 23, 2018 at 2:13 PM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > > 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. > I'd be happy to help design a new list for Fedora, if we decide to go down this road. > > 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. > There was a proposal in RPM upstream to add a concept of "tags"/"meta tags", which could be a set of properties that an RPM could be categorized under. However, the idea was not fleshed out enough for us to seriously consider it as something to support in RPM. However, I'm not sure multi-categorization makes sense beyond setting up installation groups. > 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! > This is where I think that transforming comps into metapackages would probably solve the remaining issues we have with the current workflow. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
