Bug 1385257

Summary:	combining the tag 'BuildArch' and 'BuildArchitectures' get weird results
Product:	Red Hat Enterprise Linux 7	Reporter:	Xibo Ning <xning>
Component:	rpm	Assignee:	Florian Festi <ffesti>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.2	CC:	tkopecek, xning
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-18 11:25:19 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 Xibo Ning 2016-10-15 17:05:51 UTC

Description of problem:
When using both the tag 'BuildArch' and 'BuildArchitectures', e.g., as follows

BuildArch: noarch
BuildArchitectures: x86_64

Then, if we check the RPMTAG_BUILDARCHS from the SRPM, we will get '[x86_64]', but after building the package, the rpm is a 'noarch' package.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Create a SRPM that containing both tags as follows
BuildArch: noarch
BuildArchitectures: x86_64
2. Using python 'rpm' module to check the RPMTAG_BUILDARCHS header.
3. build the package by rpmbuild or mock, then check the build results.

Actual results:
The python code returns '[x86_64]' but we get a noarch package.

Expected results:
the python code returns '[x86_64]', and we get a x86_64 arch package.

Additional info:

Comment 2 Florian Festi 2016-10-17 13:03:06 UTC

BuildArch and BuildArchitectures are aliases for the same directive. The expected behaviour is probably to give an error message. Are you trying to achieve something with this combination or did you just stumble upon this by accident?

Comment 3 Dennis Gilmore 2016-10-17 14:13:57 UTC

(In reply to Florian Festi from comment #2)
> BuildArch and BuildArchitectures are aliases for the same directive. The
> expected behaviour is probably to give an error message. Are you trying to
> achieve something with this combination or did you just stumble upon this by
> accident?

see https://pagure.io/koji/issue/19 it seems everyone except xning thinks it si a bug in rpm. not sure testing has been done on fedora. this is not really a RHEL or Fedora bug, but one I think needs to be taken upstream.

Comment 4 Florian Festi 2016-10-17 15:59:05 UTC

I really wish I hadn't read all this and hadn't seen the things I've seen.

Nevertheless, the current behaviour is clearly not intentional and I've already sketched a patch that will abort be build if two BuildArch lines are found in a (sub) package. This behaviour is clearly not something to build your build system upon.

Comment 5 Xibo Ning 2016-10-18 09:18:39 UTC

I verified that this behavior is existed on the Fedora 24, too. Just as what I have said, this behavior is there not late than 2001.

Just as the https://pagure.io/koji/issue/19 shows, "Sometimes the content in a package can be run anywhere, but some underlying dependency is only available on a subset of arches". Hence we need a way to express the restriction that a noarch package could only be built and run on some specified archs. This feature is at least required for both builders and yum repo creators.

Unless we have ExclusiveArch to include 'noarch', we cannot combine the tag BuildArch and tag ExclusiveArch, otherwise the rpmbuild will complains that 'noarch' architecture is not included. But if we have the ExclsiveArch to include 'noarch', brew will build the package once as its arch is 'noarch'. Hence this way doesn't express the restriction.

What about combining the tag BuildArch and ExcludeArch? By the ExcludeArch tag we can express that the package cannot be built on some specified archs, but by it we cannot express in what archs we can build the package.

If the SRPM cannot tell us in what archs we could build it, then there must be some external data by which we can compute these archs. And these external data should always with the SRPM and its RPMs, otherwise some tools, e.g., creatrepo, possible do something wrong.

Hence, if just combining the 3 tags, unless we give up trying to express the restriction, we need combine the tag BuildArch and ExcludeArch and bind the package with some external data. And it's no doubt that some of follow-up tools need these external data.

Comment 6 Florian Festi 2016-10-18 11:25:19 UTC

There are basically two issues here:

Finding a way how to build these semi-noarch packages and
Fixing the weird behaviour with two BuildArch lines.

Let's make this bug about the later.

I already fixed this upstream. It now errors out if it encounters a second BuildArch(itectures) line.

As this is technically an RHEL 7 bug I am closing this WONTFIX instead of UPSTREAM as we probably don't want to break builds in RHEL and though will not back port the fix.


The discussion about semi-noarch packages can either continue in the pagure ticket or - if you prefer - in another BZ.