1385257 – combining the tag 'BuildArch' and 'BuildArchitectures' get weird results

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1385257 - combining the tag 'BuildArch' and 'BuildArchitectures' get weird results

Summary: combining the tag 'BuildArch' and 'BuildArchitectures' get weird results

Keywords:
Status:	CLOSED WONTFIX
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	rpm
Sub Component:
Version:	7.2
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Florian Festi
QA Contact:	BaseOS QE Security Team
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2016-10-15 17:05 UTC by Xibo Ning
Modified:	2016-10-18 11:25 UTC (History)
CC List:	2 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2016-10-18 11:25:19 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

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.

Note You need to log in before you can comment on or make changes to this bug.