[Top][All Lists]

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

[bug#39021] [PATCH] Add Keybase

From: Leo Famulari
Subject: [bug#39021] [PATCH] Add Keybase
Date: Tue, 11 Feb 2020 12:36:34 -0500

On Tue, Feb 11, 2020 at 05:36:54PM +0100, Jakub Kądziołka wrote:
> > We strive to avoid using these, but sometimes we do, as in the Docker
> > package. It's not really idiomatic to unbundle things in Go. But we need
> > to at least make sure all the bundled dependencies are freely licensed.
> Apart from licensing concerns, what are the arguments for splitting this
> into separate packages? I feel like this is just busywork...

The question of licensing is unrelated to bundling, sorry if that wasn't
clear. The only thing you have to do here is make sure they are all
freely licensed.

To clarify, those bundled dependencies *are* separate packages,
developed by different organizations.

It's the standard in Guix (and every major GNU/Linux distro) to not
allow bundled dependencies because they make the graph of software
basically uninspectable and unmaintainable using the distro's normal
tools, as well as having the potential to waste time and space building
multiple versions of a package if it is bundled in more than one place
or already present as its own package. It negates all the advantages of
creating a distrubtion, especially for Go binaries, which can be
trivially deployed on any system, including Guix, without any extra

But like I said, it's normal to bundle things in Go land, where there is
really no principled concept of dependency management or versioned
releases, and as time goes by changes to the Go compiler make it harder
and harder to unbundle. I did do it for Syncthing and I can confirm it
was a lot of work for no clear benefit. Excepting the standard library,
Go libraries do not even get security updates because nobody is looking
closely at them.

reply via email to

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