Does it will really create noarch package? As I would expected, you could end with x86_64 rpms.

see https://bugzilla.redhat.com/show_bug.cgi?id=1298668#c11

I just tried this scratch build:

https://koji.fedoraproject.org/koji/taskinfo?taskID=42720022

And there the packages seems to be noarch. Reading https://pagure.io/pungi-fedora/issue/87 it seems that the noarch was there to allow build something, but I am not sure what actually. Maybe the SRPM could not be built without the noarch? Or does it affect the compose somehow?

@praiskup and hint please?

The problem I had before was that I wanted to ship noarch set of
(sub) packages from vim-syntastic.spec, but I wanted to blacklist certain
subpackages from specific architectures. Ie I could use the ExclusiveArch
hack -- but then it would affect all of the subpackages and the whole
set of sub-packages wouldn't be shipped. So eventually I decided to stop
shipping the affected sub-packages at all (even though those could calmly
live in x86_64 repos, e.g.).

The noarch thing is IMO https://bugzilla.redhat.com/show_bug.cgi?id=1298668 .

This is 3 years old thing, and I had to re-observe all the complicated
thing issue now => I may be wrong or outdated.

Maybe the SRPM could not be built without the noarch?

This build done by simple-koji-ci successfully built the SRPM, but that still does not prove anything:

https://koji.fedoraproject.org/koji/taskinfo?taskID=42721197

The problem I had before was that I wanted to ship noarch set of
(sub) packages from vim-syntastic.spec

Thx. So that appears to be something a bit more complex IMO. I care about ExcludeArch/ExclusiveArch in the main package.

So my doubts about the correct usage still holds ...

I've compared headers of these two resulting RPMs (F31) (ExclusiveArch: noarch x86_64 vs ExclusiveArch: x86_64) and they looks pretty same (both shows RPMTAG_ARCH: noarch, RPMTAG_PLATFORM: noarch-redhat-linux-gnu. So, it looks more like a relict.

Summoning @lsedlar - do you think, there could be some difference in these for pungi?

Pungi will treat ExclusiveArch: x86_64 and ExclusiveArch: x86_64 noarch differently. When it figures out if a package is compatible with a given arch, if noarch is there, it will be considered compatible with everything. Without noarch the package would disappear from all non-x86_64 repos.

This can be disabled in compose configuration (so that noarch in ExclusiveArch is ignored), since I would say that's actually wrong behaviour. pungi#914 added the configuration option.

@lsedlar - From where you get it? so, you're looking to SRPM and sorting binary RPMs based on this? As there is not that info in resulting rpm?

Yes, the tags are stored only in SRPM, so Pungi looks there and then pretends the same is set in all packages from that source. BTW this is one reason why different subpackages can not set the excludes differently.

Thanks for explanation! :thumbsup: