such dependency chains should not be allowed at all: https://bugzilla.redhat.com/show_bug.cgi?id=1555323#c5 Name: wireshark Requires: %{name}-cli = %{epoch}:%{version}-%{release} Requires: %{name}-qt = %{epoch}:%{version}-%{release} %package cli Requires: %{name} = %{epoch}:%{version}-%{release} cool, now we have a metapackage which requires the cli-package which itself requires the metapackage - completly useless - in that case it would be cheaper to have only "wireshark" because it reduces metadata and you can't install one without the other anyways
Policing good packaging practise is not the business of rpm but the packaging guidelines. The fact that this pattern may be useless here does not mean it is useless everywhere. Especially when dealing with dependency loops and install order issues it may make sense to split package although all parts are needed. So adding build time checks may prevent legitimate use cases. Generally packaging issue should be filed against the package in question. This has a higher chance of figuring out the reasons for the way the package is build that may not be obvious even to an experienced observer.
"Policing good packaging practise is not the business of rpm but the packaging guidelines" - no, rpmbuild is part of "rpm" [builduser@testserver:/rpmbuild/SPECS]$ rpmbuild -bb lounge-rhsoft-workstation.spec warning: bogus date in %changelog: Tue Oct 18 2017 "Generally packaging issue should be filed against the package in question" - as you can see i did that and i have enough of maintainers even try to argue and waste my time instead fix their mistakes and say thanx when they did too big changes leading in lose control in that cases guidelines saying you should this and must that are useless unless they are technically enforced
Well, there is a difference between malformed spec files (the example above should actually break the build but is left as a warning only for practical reasons) and whether the content of the packages is "completly useless" or not. In general I do not really care how you get your time wasted. But in particular I actually prefer if other people than me can help with that. The use or uselessness of the packaging guidelines is not something the rpm package will take responsibility for. While there is an argument to be made for build time enforced policies this example is not suitable to get a change of this magnitude started.