[bug#48259] [PATCH 1/2] gnu: Replace go-github-com-golang-protobuf-proto with go-github-com-golang-protobuf

[Leo Famulari <leo@famulari.name>]

On Sun, May 09, 2021 at 08:37:00PM +0800, Dion Mendel wrote:
> Is it acceptable to use bundled copies of dependencies?  The manual (section
> 16.6, checklist #6) says otherwise.

This item, from the manual section Submitting Patches, says: 

"Make sure the package does not use bundled copies of software already
available as separate packages."

So, already, there is some wiggle room based on whether or not things
are "already available as separate packages."

Using bundled dependnencies is strongly discouraged and you are expected
to try to avoid it.

With Syncthing, there were unfixed security vulnerabilities in our
package, and our go-build-system could not build later versions of
Syncthing. So, until our go-build-system is overhauled [0], we'll use
Syncthing's bundled dependencies. They are all free software anyways.

With Go, the old distro model of "no bundling" is not idiomatic, so the
future of Go in Guix may look different from how it is now. Go software
typically has no concept of "versions" and every program pins its
dependencies at specific Git commits. So, to unbundle everything would
leave us with hundreds or thousands of versions of popular libraries.
We'll have to be creative in how we deal with that.

But for now, we try to unbundle.

> If it's okay, this would make packaging lxd much simpler.  I've had to
> package around 90 Go libraries so far.
> 
> If using lxd's bundled copies of dependencies would be accepted, then I
> withdraw this patch request.

Please, either try packaging them "by hand" or with the Go module
importer [1]. Code reviewers will ask you to explain why you are using the
bundled dependencies.

[0] The work to overhaul go-build-system is progressing.

[1] https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-import.html#Invoking-guix-import
I guess it would be a command like:
`guix import go github.com/lcx/lxd --recursive -pin-versions`
But, it depends on LXD using the standard Go module mechanisms. If it
doesn't, maybe each top-level dependency can be imported along with its
dependency graph.