See https://bugzilla.redhat.com/show_bug.cgi?id=1597664 for context.
I propose we chnage https://fedoraproject.org/wiki/Packaging:Guidelines#BRP_.28BuildRoot_Policy.29_Scripts
From:
From Fedora 28, it is possible to disable any BRP script simply by undefining the corresponding variable. For example, to disable the brp-python-bytecompile script: %undefine __brp_python_bytecompile
%undefine __brp_python_bytecompile
To:
From Fedora 28, it is possible to disable any BRP script simply by defining the corresponding variable to %{nil}. For example, to disable the brp-python-bytecompile script: %global __brp_python_bytecompile %{nil}
%{nil}
%global __brp_python_bytecompile %{nil}
Emphasis on changed bits.
Yes, it seems that %undefine just doesn't work like we would really like for it to work in all cases, and unfortunately the case where redhat-rpm-config and base rpm both define the same macros is one of those cases. (The %undefine only removes the most recent definition and so unshadows the previous one, which is somewhat bizarre.)
Oh, well. I preferred the simplicity of %undefine and in most cases it does work, but it's completely baffling when it doesn't.
I just went ahead and fixed this.
Metadata Update from @tibbs: - Issue assigned to tibbs - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
%global or %define?
https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over_.25define
If %define is needed here, it may deserve a note.