+++ This bug was initially created as a clone of Bug #1577860 +++

Description of problem:

An error file is printed on every rpmlint invocation, like this:

# rpmlint ./htop-2.1.0-1.fc28.x86_64.rpm 
/usr/bin/python: can't open file '/usr/lib/rpm/python-macro-helper': [Errno 2] No such file or directory
htop.x86_64: W: only-non-binary-in-usr-lib
htop.x86_64: E: incorrect-fsf-address /usr/share/licenses/htop/COPYING
1 packages and 0 specfiles checked; 1 errors, 1 warnings.

This is only happening if rpm-build is not installed (it contains the necessary file). However, rpm-build is not a dependency for rpmlint.

Either rpmlint should require rpm-build (at least as a Recommends), or it should not print the error when not installed.

Version-Release number of selected component (if applicable):
rpmlint-1.10-5.fc27.noarch
rpm-build-4.14.1-1.fc27.x86_64

How reproducible:
always

--- Additional comment from Miro Hrončok on 2018-05-14 06:22:04 EDT ---

I've been noticing this as well (on taskotron mostly). Thanks for tracking this down.

--- Additional comment from Jason Tibbitts on 2018-05-14 11:49:33 EDT ---

This output does not come from rpmlint, though.  It is output by rpm when it performs certain operations  Just try running

rpm -E '%python_sitelib'

The problem is that the stock rpm macro file has changed to define %python_sitelib, %python_sitearch and %python_version (which aren't even supposed to be used in Fedora these days) in terms of this python-macro-helper script.  I objected to making that change but it was pushed anyway.

rpmlint explicitly tries to expand various macros in TagsCheck.py, including %python_sitearch.  If you happened to not have perl-interpreter installed (which is not possible because it's a direct dependency) you would see similar messages about perl.  If the python{2,3}-rpm-macros was changed to also use python-macro-helper (which I'm surprised hasn't been done already) then you would see additional very similar failures.

Anyway, I don't really object to rpm-build being a soft dependency in any cass, though rpm-build does have a more significant dependency footprint.  Alternately, it is probably reasonable to work around this bug by redirecting stderr before calling rpm.expandMacro, or to simply say that the RPM Python bindings shouldn't be spewing to stderr and reassign this to the rpm package.

--- Additional comment from Petr Pisar on 2018-07-04 06:31:48 EDT ---

When I removed perl from minimal build root, I noticed the error message and asked Panu to move the macros from rpm's macros file into perl's macro file. Though he insisted that he wants to keep them there. And here it is. I'm ready to adopt the Perl macros anytime.

--- Additional comment from Kamil Páral on 2018-07-10 10:23:35 EDT ---

CC Panu to move this forward.

--- Additional comment from Panu Matilainen on 2018-08-13 07:55:34 EDT ---

The simple fix is to move the python-macro-helper script to the main rpm package, that's where the macros are defined so that's where the script ought to be too.

Beyond that, yes the various language-specific macros in rpm are problematic in any number of ways. 

Petr, I have no recollection of such discussion, much less "insisting" anything regarding it. I found some perl macro related discussion from my mail email archives from 2012, if that's what you're referring to then from my POV the focus was something rather different, plus it's a BIT long in the tooth. Times are different, lots of things have changed and with the Python reorg even more things are about to change. If you're willing to deal with the possible fallout from removing the perl macros from main rpm package then I'm all for it, but please open another bug to deal with it.

--- Additional comment from Panu Matilainen on 2018-08-13 07:56:31 EDT ---

Reassigning to rpm, this isn't rpmlint's headache.

--- Additional comment from Panu Matilainen on 2018-08-13 08:41:43 EDT ---

The helper script moved to main rpm package in rpm-4.14.2-0.rc2.2.fc29

That of course only shifts the problem elsewhere (but see https://src.fedoraproject.org/rpms/rpm/pull-request/14)