[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: packaging a golang package

From: Helio Machado
Subject: Re: packaging a golang package
Date: Tue, 26 Jan 2021 00:38:59 +0100

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

On Mon, 25 Jan 2021 at 21:49, JOULAUD François <> 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?
> > >
> New version of the patch on
> 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 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]:
> [2]:
> [3]:
> [4]:
> [5]:
> [6]:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]