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 Fedora"
> <packaging(a)lists.fedoraproject.org>
> Cc: golang(a)lists.fedoraproject.org, "Jakub Cajka"
<jcajka(a)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.
> > 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
Which is not yet there, right?
Which is being worked on by rpm upstream, just like I'm working on the
corresponding generator for go modules (we already have a generator for
pre-module world, even though it is based on golist not the dep analysis
upstream created for go modules).
No having a generator at Go module time will mean every Go packager will
have to perform go.mod analysis and translation to rpm deps manually,
for every single Go project we package.
--
Nicolas Mailhot