(Quick note: my patches follow the third approach, not the second) On Mon, 25 Jan 2021 at 21:49, JOULAUD François < francois.joul...@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
