go-macros produces different noarch packages on different arches

[eclipseo]

See scratch build https://koji.fedoraproject.org/koji/taskinfo?taskID=25619962 :

BuildError: The following noarch package built differently on different architectures: golang-bazil-fuse-devel-0-0.3.20180310git371fbbd.fc29.noarch.rpm
rpmdiff output was:
error: cannot open Packages index using db5 - Permission denied (13)
error: cannot open Packages database in /var/lib/rpm
error: cannot open Packages database in /var/lib/rpm
removed     /usr/share/gocode/src/bazil.org/fuse/syscallx/msync_amd64.go

The file syscallx/msync_amd64.go is only included on x86_64 resulting indifferent noarch packages. All the files should be the same for all noarch packages, whatever the arch it is build from. No files should be removed from the source, even the not useful ones for that arch.

[eclipseo]

Also the sources of golist are not available anywhere which makes it hard to diagnose the issue ans it ethically dubious.

[nim-nim]

golist sources are hidden there https://github.com/gofed/symbols-extractor/

They rebuild fine (my co-compiler spec starts by removing the golist binary) but should really use their own src.rpm

[nim-nim]

And, BTW nothing stops you from declaring the -devel package of such a project as arch-specific (which it is)

[ingvagabund]

@eclipseo we have two choices. Either ship all arch-specific files and declare the -devel subpackage as noarch. Or ship arch specific files only on specific architectures. I prefer the latter cause it forces you to switch to arch-specific rpm (removing the Buildarch: noarch tag). Though, you can create a special noarch devel subpackage that ships all the arch specific files as noarch and have the main devel subpackage require the special one.

Even if the devel subpackage ships "only" source code, there are cases where it is good to consider it as arch specific. I hit an issue on arm where a Go source code needed a dynamic library that was available everywhere except arm. So even if there was no arch specific Go file, I was not able to build the package on arm which made it arch specific.

[eclipseo]

Today I learned:

It may be tempting to make the header library package noarch, since the header files themselves are simply text. However, a library should have tests which should be run on all architectures. Also, the install process may modify the installed headers depending on the build architecture. For these reasons, header-only packages must not be marked noarch.

https://fedoraproject.org/wiki/Packaging:Guidelines#Do_not_use_noarch

Thus feel free to close as Invalid.

[ingvagabund]

Thanks for more clarification.