.rpmmacros taint SRPM and inhibit --rebuild

[Jeff Johnson]

tracker: justification for starting to use %{load:...}

[John (john-redhat-bugs)]

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):
rpm-build-4.8.1-5.fc14

How reproducible: every time

Steps to Reproduce:
1. rpmbuild --rebuild glibc-2.12.90-19.src.rpm
2.
3.

Actual results:
error: Installed (but unpackaged) file(s) found:
   /usr/lib/debug/usr/lib64/libBrokenLocale.a
   /usr/lib/debug/usr/lib64/libanl.a
   ...

Expected results: successful re-build.

Additional info:

[Fedora (fedora-redhat-bugs)]

This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.

[Panu (panu-redhat-bugs)]

Reproducability of builds requires identical environment, and macro setup is obviously an essential part of this: for some purposes values in ~/.rpmmacros are essential, for others they are harmful but rpm has no way of knowing which one is which.

This is a packaging/distro policy issue: in Fedora packages need to be rebuildable in mock without additionaly private macro setup, and if they're not its a packaging, not rpm bug.

[John (john-redhat-bugs)]

It is both a Functionality and a Usability bug in rpm that rpmbuild does not track the origin of macros, and optionally give a warning when a macro is used that arises from somewhere other than the .spec file or the invoking command line. The conscientious packager wants to learn as soon as possible whether the .spec is portable, and should not have to wait for a build under mock when an ordinary rpmbuild could suffice. Building under mock is an extra step that is cumbersome and expensive (big and slow.) rpmbuild is not necessarily cheap, but it is required anyway just to check whether the .spec works at all. If requested, then that same rpmbuild should say whether the .spec is portable with respect to use of macros.