On Tue, Apr 2, 2019 at 6:17 PM Nicolas Mailhot <nicolas.mailhot@laposte.net> wrote:
Le 2019-04-02 14:51, Jakub Cajka a écrit :
> ----- Original Message -----
>> From: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>
>> To: "Discussion of RPM packaging standards and practices for Fedora"
>> <packaging@lists.fedoraproject.org>
>> Cc: golang@lists.fedoraproject.org, "Jakub Cajka" <jcajka@redhat.com>
>> Sent: Tuesday, April 2, 2019 1:27:09 PM
>> Subject: Re: [Fedora-packaging] Re: Translating Go modules
>> buildrequires in rpm syntax
>>
>> 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.
>
> And they are part of the checked in source tree of the respective Go
> project, if I'm not mistaken.

And upstream tools check and regenerate the go.mod file at the slightest
occasion.

So, basically, having rpm parse exactly this file is not a problem,
because if a packager disagrees with the content of this file, but does
not fix/patch it, go tools will ignore the packager and obey the go.mod
file anyway.

I usually disagree with Nicolas, but this is the point where he gets +100 from me. Reflecting upstream constraints in RPM is essential. People do not just use distro repos, they build their own packages and such. In this case, we should be very strict about what content should be in buildroot and on user's systems. Otherwise you will get a lot of bugreports like "this golang module doesn't compile since last update" (which is because we didn't have proper info in RPM requires).