Bug 1555445

Summary: cross-dep-chains should not be possible
Product: [Fedora] Fedora Reporter: Harald Reindl <h.reindl>
Component: distributionAssignee: Václav Pavlín <vpavlin>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 27CC: dennis, ffesti, ignatenko, kevin, mjw, packaging-team-maint, pmatilai, pmoravco, vmukhame
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-15 10:16:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Harald Reindl 2018-03-14 17:48:12 UTC 
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
Comment 1 Florian Festi 2018-03-15 10:16:13 UTC 
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.
Comment 2 Harald Reindl 2018-03-15 10:23:34 UTC 
"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
Comment 3 Florian Festi 2018-03-15 10:51:13 UTC 
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.