On Wed, Apr 3, 2019 at 3:26 AM Jakub Cajka <jcajka(a)redhat.com> wrote:
----- Original Message -----
> From: "Igor Gnatenko" <ignatenkobrain(a)fedoraproject.org>
> To: "Discussion of RPM packaging standards and practices for Fedora"
> Cc: golang(a)lists.fedoraproject.org, "Jakub Cajka"
> Sent: Tuesday, April 2, 2019 6:40:27 PM
> Subject: Re: [Fedora-packaging] Re: Translating Go modules buildrequires in rpm
> On Tue, Apr 2, 2019 at 6:17 PM Nicolas Mailhot < nicolas.mailhot(a)laposte.net
> > wrote:
> Le 2019-04-02 14:51, Jakub Cajka a écrit :
> > ----- Original Message -----
> >> From: "Nicolas Mailhot" < nicolas.mailhot(a)laposte.net >
> >> To: "Discussion of RPM packaging standards and practices for
> >> < packaging(a)lists.fedoraproject.org >
> >> Cc: golang(a)lists.fedoraproject.org , "Jakub Cajka" <
> >> 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
> >> > 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
> 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
> module doesn't compile since last update" (which is because we didn't
> proper info in RPM requires).
Actually same here as he is mentioning that he is working on the packaging automation.
Without it IMO would be case for concerns. With it, it is awesome and I'm looking
forward to it.
To the original query, how I see it is that our (Build)Requires should
structure as accordingly:
BuildRequires: (golang-module(foo) >= 1.0.0 unless (golang-module(foo)
= 1.1.5 or golang-module(foo) = 1.2.0))
真実はいつも一つ！/ Always, there's only one truth!