koji

#3880 Do not build noarch packages with --target noarch
Closed: Invalid by tkopecek. Opened by fweimer.

Closed: Invalid
Reopen Issue

Using --target noarch breaks the automated setting of key RPM macros. For example, even for an x86_64 buildroot, _libdir is suddenly /usr/lib. This can prevent the correct execution of the build if it is necessary to construct a _libddir path for the build itself (%install obviously must not depend on %_libdir).

This came up during the following bug:

To get --target x86_64_v4 to actually pass -march=x86-64-v4 to GCC, we need to change %optflags, but if we do that, the value generated for --target noarch changes as well, producing x86-64-v4 binaries on Fedora builders even though no one requested that.

So, what would be best approach here? Just drop --target noarch? Is it releveant only for binary rpms or also srpms?

Metadata Update from @tkopecek:
- Custom field Size adjusted to None

I expect some unexpected consequences from dropping it. Is it possible to determine why it was added?

The same issue would be present on the SRPM stage, but given the limited code execution there, it should matter even less.

Yep, I'm not hurrying with removal - just trying to get grasp of the whole issue. It was added more times to different stages, e.g. https://pagure.io/koji/c/28386ee4d3c3dd2e98e4099b72034f9eb80acee8
@mikem could remember more.

For buildArch it is more "automatic" propagation of build's arch, so not sure if here it was a specific reason or not.

No no. Koji is doing the right thing in passing --target noarch (well, any buildarch), no reason to remove it. It's the undefined muck on rpm and packaging side that is running into trouble here.

Edited by pmatilai

This is very longstanding behavior on Koji's part. Passing --target noarch (to mock) when building for noarch is a natural way for Koji to communicate the target to the underlying tools.

Given Panu's comment, it looks like we should reject this. Sounds like a regression in the underlying tools, and I don't think it is right to work around it by introducing a backwards-incompatible change here.
Edited by mikem

It's not even a regression in the underlying tools, just a circumstance we had never seen before. Basically a combination of
- new subarchitectures added upstream without also adding them to redhat-rpm-config (because there's no intention to build optimized versions on Fedora side)
- redhat-rpm-config setup becoming complex enough that builds downright fail with upstream config
- some noarch packages depending on buildhost specific bits (%optflags in particular) in a way at least I haven't seen before

...which dragged into the light a bug about a quarter century old in rpm. Which is getting fixed now, hopefully.

Metadata Update from @tkopecek:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

fwiw, some historical context:

The change Tomas linked above (28386ee4d) was prompted by https://bugzilla.redhat.com/show_bug.cgi?id=1021001

However, when performing noarch rpm builds, Koji has passed --target noarch since 2008 (and it passed --arch noarch before that. See commit c939b34ff.

Oof, thanks for that pointer. Some of the dragons mentioned there are still circling around :laughing:

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/3880

Please continue any further discussion there.
Metadata
None
None
None
None
Low
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.