Improve integration

[nim-nim]

This one actually recurses as intended

[nim-nim]

A correct layout IMHO is:

1. a first arched srpm with https://github.com/gofed/symbols-extractor/ as upstream project, that builds

   • one arched rpm with /bin/golist inside

2. a second srpm with https://github.com/gofed/go-macros/ as upstream project, that builds,

   • one noarch go-srpm-macros subpackage that ships macros.go-srpm and is in the default buildroot. it includes %gometa that adds a BR on go-rpm-macros to go packages
   • one noarch go-rpm-macros with everything else except the compiler-specific macro files, that Requires: golang(go-compiler) and golist
   • one arched compiler subpackage (go-compilers-golang or go-compilers-gcc depending on the arch), with the correct compiler-specific macro for the arch. Provides golang(go-compiler). And I'm not 100% of the benefit of having different names depending of the compiler, but since it's already there it can be kept

[ingvagabund]

A correct layout IMHO is:

1. a first arched srpm with https://github.com/gofed/symbols-extractor/ as upstream project, that builds

   • one arched rpm with /bin/golist inside

2. a second srpm with https://github.com/gofed/go-macros/ as upstream project, that builds,

   • one noarch go-srpm-macros subpackage that ships macros.go-srpm and is in the default buildroot. it includes %gometa that adds a BR on go-rpm-macros to go packages

As I argued before the go-srpm-macros will not be part of the go-compilers. The go-srpm-macros is installed in every buildroot and any change, if not carefully implemented, can break the buildroot. Thus, the go-srpm-macros must live on its own and has only a limited number of packagers with commit permissions. So this is no-go.

• one noarch go-rpm-macros with everything else except the compiler-specific macro files, that Requires: golang(go-compiler) and golist

Yes, this will improve the semantics of the files as they will be properly distributed among arch specific and arch independent rpms. Though, I don't see this as a pressing or blocking issue or anything that has direct impact on the functionality of currently provided macros. Maybe sometimes in the future.

• one arched compiler subpackage (go-compilers-golang or go-compilers-gcc depending on the arch), with the correct compiler-specific macro for the arch. Provides golang(go-compiler). And I'm not 100% of the benefit of having different names depending of the compiler, but since it's already there it can be kept

Naming is very important. I am fun of expressing meanings explicitly. Given both go-compilers-golang and go-compilers-gcc are never directly BuildRequired (that's why the virtual golang(go-compiler) exists at the first place), I don't see a reason to bother with it.

[ingvagabund]

The discussion on the PR is getting multiple directions. Please, break the PR into smaller ones so I can merge at least some parts of it. E.g.

• compensate for golist not owning all project Go packages and breaking (still arguable)
• To build a Go package, you need go-rpm-macros to pull in golist (still arguable)
• builds and checks need access to the built binaries, use the usual (can me merged right away)
• prettify build logs + Simpler messages squashed (can be merged right away)
• simplify, hopefully make more robust, handle md files natively (could be merged after some clarification)