Bug 1040273

Summary: %__xz macro broken
Product: Red Hat Enterprise Linux 5 Reporter: Ralf Corsepius <rc040203>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.11CC: ffesti, jzeleny, pmatilai
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-17 13:23:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Ralf Corsepius 2013-12-11 05:38:17 UTC
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.

Comment 1 Florian Festi 2013-12-17 13:23:07 UTC
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.

Comment 2 Ralf Corsepius 2013-12-17 13:44:29 UTC
(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.

Comment 3 Jan Zeleny 2013-12-17 14:48:38 UTC
(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