The fundamental problem is that the Python 3 transition has mutilated the once
simple Python landscape into something barely recognizable. Rpm cannot possibly
know what the "default python" is when such a thing no longer exists -
/usr/bin/python could point to anything at all or not even exist,
A simple way to achieve this would be running the build-scripts inside a
transient systemd unit. This is enough to make the reproducer to not hang
around:
```--- a/macros.in
+++ b/macros.in
@@ -792,9 +792,10 @@ package or when debugging this package.\
# Global defaults used for building
Maybe `%autosetup` should be "internalized" in `parsePrep.c` alongside
`%setup`? For the most part – after groking and converting some options – it
would call `doSetupMacro()` (plus `%autopatch`).
Moreover, it would be possible to issue a more useful diagnostic if the user
requests an unknown
Internalizing %autosetup in order to handle multiple identical position
sensitive options in the already internalized %setup makes little sense: the
goal was to permit users to change templating without recompiling rpm.
Better error messages can certainly be attempted by testing for
None of systemd-nspawn, systemd-run, mock or Koji or (for that matter) bash
have much to do with rpmbuild.
Expecting rpmbuild to solve complex issues involving runtime environment
cleanup is bad craziness.
You might consider -- say -- reporting an RFE to systemd or mock or koji or
bash to
What about anything that calls `%autosetup`? You have to stop somewhere.
Better would be to give sufficient expressiveness to the macro language to
handle repeated arguments, and perhaps not need magic internal macros at all.
Or maybe just add a Lua argument parsing library as standard and
If I remember correctly, I met this issue running rpmbuild inside mock, which
is actually using systemd-nspawn, which complained during the container
shutdown. Moreover, I think that systemd-run is not available inside mock, so I
am not convinced this is the right solution.
--
You are
I should point out that multiple identical position sensitive option values end
up as a stack of values even with getopt(3) parsing, and that the stack of
option values could recreate the list of -a values to pass to %setup using the
proposed syntax %{-@a: -a}, thereby fixing this issue.
First of all, there is nothing forcing anyone to use %autosetp, nor anything
preventing anyone from redefining %autosetp to whatever is wished, including
adding better diagnostics.
Meanwhile the flaw is in %setup through over-thinking, a design flaw that goes
back to at least 1997.
If you
