Anyone against me merging this?

See my comments in the upstream PR: https://github.com/rpm-software-management/rpm/pull/469

Consider this a temporary fix. Feel free to provide a better one tough, I don't understand macro expansion as well as you do., but this is causing trouble and needs to be somehow sorted ASAP.

How about moving the macros to someplace in the python land? That way the macros would be undefined when python is not present so you don't need to fake it like this.

Let's just undefine those entirely?

I don't have any particular attachment to those macros, if somebody's willing to deal with the fallout, by all means.

What I do object to is adding more crud to make defined macros look like undefined ones.

Those macros are supposed to work if you redefine __python. Thay lack error handling if you define __python to nonexisitng command.

So how about turning the non-versioned use into an actual parse error, eg:

--- a/macros.in
+++ b/macros.in
@@ -50,7 +50,7 @@
 %__mv                  @__MV@
 %__patch               @__PATCH@
 %__perl                        @__PERL@
-%__python              @__PYTHON@
+%__python              %{error: attempt to use non-versioned python}
 %__restorecon          @__RESTORECON@
 %__rm                  @__RM@
 %__rsh                 @__RSH@

With that, trying to build a package that hasn't explicitly set %__python to one version or the other will get an error like this:

[pmatilai@sopuli SPECS]$ rpmbuild -bb deltarpm.spec 
error:  attempt to use non-versioned __python
error: line 129: %{python_sitearch}/*

[pmatilai@sopuli SPECS]$ 

There are packages that rely on __python being python (unfortunately). See for example this PR where I fixed it: https://src.fedoraproject.org/rpms/python-shortuuid/pull-request/2#request_diff

Sure there are, but in that case you just define %__python to "python" in the spec. It'd be an explicit error requiring explicit action.

That makes sene, but it is something that needs proper announcement, maybe change even.

Can we only set %{error: %{__python} command failed} if %python_sitelib definition actually fails?

Not quite, but you could define %__python to /usr/bin/python from python-unversioned-command package to that effect.

Still if users define python to /usr/bin/asdfghjkl, they is no error handling. A proper solution errors when python_sitelib etc. definition returns nonzero.

Well it is what it is. Turning shell expansion failure into an actual error in the macro engine would be trivial technically but people are relying on the no-error behavior for various situations.

Can we turn shell expansion failure into an actual error only when a special opt in mechanism is used and use that for python_sitelib etc.? as you propose in https://github.com/rpm-software-management/rpm/pull/469#issuecomment-410958585

The problem is that the only sane behavior is the other way around: error by default and opt-out with ? or something like that. And we can't just go and change the behavior in a stable rpm version, nor do we want to deviate from upstream behavior in such a way in Fedora.