.rpmmacros taint SRPM and inhibit --rebuild
Bug #913633 reported by
Jeff Johnson
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
RPM |
New
|
Undecided
|
Unassigned | ||
Fedora |
Invalid
|
Medium
|
Bug Description
tracker: justification for starting to use %{load:...}
tags: | added: fedora macros |
Changed in fedora: | |
importance: | Unknown → Medium |
status: | Unknown → Invalid |
To post a comment you must log in.
Description of problem: "Private" macros that are not defined in the .spec (but are defined in places such as .rpmmacros) can leak into a .srpm without warning. Often the effect is to make a subsequent --rebuild of the generated .src.rpm impossible unless you know about the private macro. For instance, %_enable_ debug_packages in glibc-2. 12.90-19. src.rpm (bug #658186; bug #653905). In the expression part of an %if or %ifarch, then rpmbuild should detect any macros that do not originate from the .spec file itself. A warning would be OK for -bp, -bc, or -bb; but it should be an error for -bi, -ba, or -bs (any step which installs results into BUILDROOT, or which creates a .srpm.)
Version-Release number of selected component (if applicable): 4.8.1-5. fc14
rpm-build-
How reproducible: every time
Steps to Reproduce: 12.90-19. src.rpm
1. rpmbuild --rebuild glibc-2.
2.
3.
Actual results: lib/debug/ usr/lib64/ libBrokenLocale .a lib/debug/ usr/lib64/ libanl. a
error: Installed (but unpackaged) file(s) found:
/usr/
/usr/
...
Expected results: successful re-build.
Additional info: