all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Leo Famulari <leo@famulari.name>
To: "Jakub Kądziołka" <kuba@kadziolka.net>
Cc: 39021@debbugs.gnu.org
Subject: [bug#39021] [PATCH] Add Keybase
Date: Tue, 11 Feb 2020 12:36:34 -0500	[thread overview]
Message-ID: <20200211173634.GB9442@jasmine.lan> (raw)
In-Reply-To: <20200211163654.v5jz5bf7audo7unh@gravity>

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
work.

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	other threads:[~2020-02-11 17:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-07 20:00 [bug#39021] [PATCH] Add Keybase Jakub Kądziołka
2020-01-24 18:34 ` [bug#39021] go package rebuilds Jakub Kądziołka
2020-01-28 21:54 ` [bug#39021] [PATCH 1/2 v2] build-system/go: Allow providing additional build flags Jakub Kądziołka
2020-02-08  0:20 ` [bug#39021] [PATCH] Add Keybase Leo Famulari
2020-02-11 16:36   ` Jakub Kądziołka
2020-02-11 17:36     ` Leo Famulari [this message]
2020-05-31  7:09       ` Efraim Flashner
2020-05-31 21:47         ` Jakub Kądziołka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200211173634.GB9442@jasmine.lan \
    --to=leo@famulari.name \
    --cc=39021@debbugs.gnu.org \
    --cc=kuba@kadziolka.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.