Hide Forgot
Description of problem: On EPEL5's rpm defines %__xz as follows: # rpm --showrc | grep xz __xz %{_bindir}/xz This macro seems to be used by rpmbuild when unpackaging xz-compressed source tarballs. This works as long as rpm.specs do not modify %_bindir, but fails when they do so: From a mock build.log on EPEL5: ... + cd rtems-4.11-v850-rtems4.11-gcc-4.8.2 + tar -xf - + /opt/rtems-4.11/bin/xz -dc /builddir/build/SOURCES/gcc-4.8.2.tar.xz /var/tmp/rpm-tmp.41510: line 39: /opt/rtems-4.11/bin/xz: No such file or directory tar: This does not look like a tar archive tar: Error exit delayed from previous errors error: Bad exit status from /var/tmp/rpm-tmp.41510 (%prep) ... Version-Release number of selected component (if applicable): rpm-4.4.2.3-34.el5 How reproducible: Always. Steps to Reproduce: 1. Take an rpm.spec which contains a tar.xz-compressed Source* 2. rpmbuild --define '_bindir /opt/foo' ... Actual results: - Building packages, which contain *.tar.xz's, under EPEL5 only works, if %_bindir is /usr/bin. Additional info: EPEL6 and Fedora define __xz with a hard-coded /usr/bin instead of %_bindir. This is correct, because %_bindir is a user-modifiable input parameter to rpm-build while /usr/bin/xz is a system feature.
While this clearly is a bug this does not justify issuing an update of the rpm package. In case you really need to do this please redefine the macro yourself. Thank you for your understanding.
(In reply to Florian Festi from comment #1) > While this clearly is a bug this does not justify issuing an update of the > rpm package. In case you really need to do this please redefine the macro > yourself. Thank you for your understanding. Please understand that I consider your answer to be inappropriate and your request to clutter *spec files with cludges to work around defects of your products to be inacceptable. I regret, but this once more fuels my perception of Red Hat not behaving as a fair partner in Fedora EPEL.
(In reply to Ralf Corsepius from comment #2) > (In reply to Florian Festi from comment #1) > > While this clearly is a bug this does not justify issuing an update of the > > rpm package. In case you really need to do this please redefine the macro > > yourself. Thank you for your understanding. > > Please understand that I consider your answer to be inappropriate and your > request to clutter *spec files with cludges to work around defects of your > products to be inacceptable. > > I regret, but this once more fuels my perception of Red Hat not behaving as > a fair partner in Fedora EPEL. Please don't think that we don't care about EPEL. The problem is that rpm is *not* an EPEL package. It's core RHEL package and there we have to follow a different set of rules for issuing updates that are much more strict than in Fedora and EPEL. Thanks for understanding