Le 2019-04-02 12:52, Jakub Cajka a écrit :
I might have not been clear, sorry. My point is more that we
don't
need to recreate/capture the constrains in the spec files/RPM as they
are already capture in the Go source code,
In the Go module world the constrains are in the module files, not in
the source files. If you don't satisfy the constrains in your build root
lots of go commands will break. So you better tell the rpm tooling what
the constrains are so build roots are populated correctly.
creating part that needs to be (manually) maintained up to date,
There's nothing to maintain manually if you integrate properly with rpm.
That's why spec generators like gofed, that try to avoid the rpm
integration part, do not pass the maintainability test.
Integrating properly means
https://github.com/rpm-software-management/rpm/issues/104
while the GC tooling will enforce them anyway.
ie builds will fail because the build environment is not populated
correctly. It'd rather populate it automatically and correctly by
default than wait for builds to fail and then spend time on manual
workarounds because the tooling does not help me.
--
Nicolas Mailhot