This reverts commit 0a944b345e, reversing
changes made to 61733ed6cc.
I dislike these massive stdenv changes with unclear motivation,
especially when they involve gratuitous mass renames like NIX_CC ->
NIX_BINUTILS. The previous such rename (NIX_GCC -> NIX_CC) caused
months of pain, so let's not do that again.
(cherry picked from commit ec8d41f08c)
Patch away two things:
- %_includedir, %_oldincludedir, %_mandir, %_infodir macros from
lib/rpm/platform/*/macros to avoid cycles between outputs. Hopefully
anything doesn't really need those.
- Change %__ld, %__nm, %__objcopy, %__objdump in lib/rpm/macros to
refer to the commands in PATH. Should be safe as %__cc for instance is
already like that.
Commit 5dff3c4b68 made rpm use autoreconfHook, so the patch that we
are making to `configure` gets lost when the file is regenerated.
To fix this, just patch the equivalent string in the `configure.ac` file
instead.
Fixes#15287
It turns out that a surprising number of common packages use lua
scripts in RPM files, and not having lua can lead to obscure failures.
The propagatedBuildInputs stuff makes the librpm stuff more useful,
since some of its headers didn't work without extra buildInputs before.
Currently, building RPM with `python = python3` causes this:
checking for a Python interpreter with version >= 2.6... python3
checking for python3... /nix/store/dykqxnrwiz9drlcv2wy8lpvl3xvklx0g-python3-3.4.3/bin/python3
checking for python3 version... 3.4
checking for Python.h... yes
checking for library containing Py_Main... no
configure: error: missing python library
That comes from this snippet in configure.ac:
AC_SEARCH_LIBS([Py_Main],[python${PYTHON_VERSION} python],[
WITH_PYTHON_LIB="$ac_res"
],[AC_MSG_ERROR([missing python library])
])
So it's looking for (e.g) `libpython3.4.so` wheras we have `libpython3.4m.so`.
Patching the configure script to match seems to make that work (although
I don't really understand what the heck is this 'm' business about).
