Re: packaging a golang package

[Helio Machado <0x2b3bfa0@gmail.com>]

(Quick note: my patches follow the third approach, not the second)

On Mon, 25 Jan 2021 at 21:49, JOULAUD François <
Francois.JOULAUD@radiofrance.com> wrote:

> Hello,
>
> On Sun, Jan 17, 2021 at 02:31:39PM +0100, Helio Machado wrote:
> > Looks like it ran into the replace syntax and didn't parse it correctly?
> > > https://golang.org/ref/mod#go-mod-file
>
> New version of the patch on https://issues.guix.gnu.org/issue/44178#10
> fixes some of those problems. There is still others bugs left but you
> could give it a new try. Git repo with patch applied is available at [6]
>
> > Guix seems to have a strong opinion about dependency vendoring, but it's
> > technically viable as long as you don't produce architecture-specific
> > artifacts when packaging. See https://issues.guix.info/43872 for more
> > information about the pitfalls I encountered while packaging go-ethereum
> > the fast way.
>
> It seems to me we have three possible ways to handle Go packaging.
>
> First is to use vendored dependencies (when upstream provides them). This
> one has the merits of simplicity (as we just have to download the
> source and launch `go build` or whatever is needed) and less risks of
> bugs. The downsides are known: difficult to audit Licences, duplication
> of code source, difficulty to follow security bugs, etc.
>
> Second is to re-vendor package from go.mod (coming directly from code
> source or synthetized from source) by creating a source derivation
> including all dependencies. This is the strategy followed by Nixpkgs
> as explained in [1]. (It seems to me this is the route followed in
> the patches to  from Helio in [2] but I did not take the time to read
> them.) With this approach we still have some of the downsides of using
> vendored upstream but it is at least easier to verify the existence
> of upstream.
>
> Third is to package every dependencies. This is the most transparent way
> and the one that leads to less code duplication but the downside is the
> difficulty to scale with the number of packages (even if the objective of
> patch at [3] is to automate it) and the need to have only one reference
> version for each package in the distribution which have its own share of
> problems (one of them being that we don't use those tested by upstream
> as stated in [4]).
>
> I think Guix should support all three in its tooling to be able to support
> several use-cases. For inclusion of packages in Guix proper we should try
> the individual packaging of dependencies and see how it works. Perhaps we
> will need exceptions as the one Debian does for Kubernetes [5]. Perhaps
> we will need to fallback to vendoring or re-vendoring in more cases but
> we will learn as we walk.
>
> Best regards,
> François
>
> [1]: https://github.com/NixOS/nixpkgs/issues/84826
> [2]:
> https://github.com/0x2b3bfa0/guix-go-modules/commit/5defe897065c5d3e63740932b360474132c77877
> [3]: https://issues.guix.gnu.org/issue/44178#10
> [4]: https://github.com/NixOS/nixpkgs/issues/84826#issuecomment-616663815
> [5]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971515
> [6]: https://github.com/kat-co/guix/tree/create-go-importer