Bug 569541

Summary: check for dependency on non-virtual main package
Product: [Fedora] Fedora Reporter: Thomas Spura <tomspur>
Component: rpmlintAssignee: Ville Skyttä <ville.skytta>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: manuel.wolfshant, tmz, ville.skytta
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-02 17:28:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
test case spec none

Description Thomas Spura 2010-03-01 16:59:18 UTC
Created attachment 397124 [details]
test case spec

Description of problem:
When having subpackages, that require the main package, but the main package has a empty %files section (->virtual package) this is considered as 'Your package has broken dependency'.

It would be great to have this detected before doing the build and get a mail about broken dependencies from the buildsystem.

Sure this should be detected within a review, but this is not that easy to detect in a very big spec with many subpackages.

Version-Release number of selected component (if applicable):
rpmlint-0.94-1.fc12

How reproducible:
always

Steps to Reproduce:
1. rpmlint %{attachment}
  
Actual results:
In this example are two warnings:
- non-standard-group
- invalid-url

Expected results:
- non-standard-group
- invalid-url
another *error*:
** - wrong-dependency ** (or something else)

Comment 1 Ville Skyttä 2010-03-02 17:28:53 UTC
Your example does not have a %files section for the main package at all (it is not empty, it's missing) which does not mean that the main package is a virtual package, it means that the main package does not get built at all from this specfile, or in other words, the main package does not exist at all as far as this specfile is concerned.

The "main package" might be a Provides in some other package, or it could be built from a different source package - it is not necessarily a packaging bug - and rpmlint does not know about things originating from different packages.  Additionally adding a check like this might be a bit hard to implement and given the (IMHO) questionable/rare benefits and potential for noise, I don't think it's worth the trouble.

If you feel differently, feel free to open a bug upstream at http://rpmlint.zarb.org