Bug 100916

Summary:	Make rpmbuild warn when explicit __find_requires (etc) ignored.
Product:	[Retired] Red Hat Raw Hide	Reporter:	Ralph Loader <suckfish>
Component:	rpm	Assignee:	Jeff Johnson <jbj>
Status:	CLOSED WONTFIX	QA Contact:	Mike McLean <mikem>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1.0	CC:	mitr, strobert
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:	2003-07-29 12:57:28 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:

Description Ralph Loader 2003-07-27 02:41:52 UTC

rpmbuild now seems to use builtin generation of requires (& provides).

This silently breaks .spec files that attempt to modify the requires generation
by changing __find_requires.

It would be nice if this breakage was not silent.  Something like:

if __find_requires is changed and _use_internal_dependency_generator != 0 then
print a warning message.

Alternatively, maybe overriding __find_requires could automagically turn off the
internal dependencies.

BTW there are some packages in severn that have been bitten by this (e.g.,
libao).  Not sure how many.

Comment 1 Jeff Johnson 2003-07-29 12:57:28 UTC

I disagree. %__find_requires needs to be removed entirely, will
happen at my earliest opportunity.

Comment 2 Steven Roberts 2005-09-06 08:34:43 UTC

Curious as to why you are thinking of removing __find_requires.  we use this
often on custom rpms to filter out bogus deps.  an Example:
the RPM includes samples or example or contrib binaruies that require lots of
extra packages to run but the core/real parts of the RPM itself run just fine
without the other packages.  so if we can't filter out these "bogus" deps then
we would have to install using --nodeps which is not a good thing in my mind.

or is there some other option?

which setting _use_internal_dependency_generator to 0 fixed things for me.