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 _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
