[PATCH] Add package go-ethereum

# Add package `go-ethereum`

These patches add the [go-ethereum][5] package and a small workaround that

allows experimental module support.

## [Checklist][1]

1. Code authentication: all the code is being pulled from Git repositories

and Go packages, so there isn't any specific code signature we can verify.

2. Synopsis and description: built from the official documentation and

around the style guidelines.

3. Results for `guix lint`: everything seems to be fine, and it seems to

have scheduled a [Software Heritage][2] archival (?).

4. Native build check: the package builds correctly on my platform

(x86-64), using `guix build` package.

5. Cross-build check: package was not tested on any other supported

platform because `go-build-system` [doesn't seem to support

cross-compilation][3].

6. Package deduplication: dependencies are being pulled from their

respective module repositories at build time; there isn't practically any

overlap between the package code and the Guix repositories.

7. Package size: as per `guix size`, this package requires a total of 418.7

MiB, with a package (self) size of 282.4 MiB.

8. Dependent packages: this is a freshly added package with no dependent

items.

9. Deterministic build: this package is fully deterministic and has fixed

hashes for both the initial download and the build derivation.

10. Inclusive language: documentation was written with neutrality in mind

and there isn't any obvious bias, though it might need proofreading.

11. Patch atomicity: this patch contains only one set of related changes,

though modifications affect two files.

12. Code formatting: added lines were formatted by using `indent-code.el`.

13. Source consistency: all the involved downloads are being pulled along

with a Git tag or commit, so results should be consistent enough.

14. Guix build: these changes don't affect Guix builds nor introduce any

warning.

15. Guix consistency: these changes do not break Guix in any obvious way.

## Desiderata

It would be great to have easier ways to replace Go module management

system with Guix in a seamless and painless way. Rust build system for Guix

has a cleaner implementation, majorly due to the existence of a

[centralized package registry][4].

[1]: https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html

[2]: https://www.softwareheritage.org/

[3]:

[4]: https://crates.io

[5]: https://github.com/ethereum/go-ethereum

[6]: https://gist.github.com/0x2b3bfa0/1805037bf5efa2655fa71d32e69fdd14

This patch was a big hack and breaks on every architecture but x86-64

because the derivation hash changes when producing different binaries. I'm

leaving this for reference as it might be useful for a casual install, but

the proper solution probably involves a complete refactoring of the Guix Go

Build System.

Hi!

Helio Machado <0x2b3bfa0@gmail.com> writes:

That is a very clever hack. :-)

The reason it works is because network access is allowed for

fixed-output derivations. So the Go build system is able to go online

and download everything it needs, instead of relying on declared

inputs. That is why different architectures produce different

derivation hashes: those are the build outputs.

The problem with this approach is that it is not deterministic. The

next time someone runs the same build, one of the Go dependencies may

have changed (i.e. a git tag has been overwritten, or a package declares

a dependency on a branch instead of a tag, etc).

Guix will detect if the output hash changes, but is unable reproduce the

earlier state because it does not know what has changed.

To properly package go-ethereum, you will need to declare each

dependency as separate packages. See e.g. 'syncthing' for an example.

Unfortunately there is no importer for Go yet, making it a rather

tedious task.

Since you don't seem to be afraid of hacking on Guix :-) consider

writing an "importer" for Go so you could simply:

guix import go -r github.com/ethereum/go-ethereum

...to create the necessary boilerplate.

Thanks!

Hi!

I started yesterday to improve the Go build system and create a solid

recursive importer. It implies some structural change for every package,

but it's probably worth it and I'll submit a new patch once it's ready.

I'm attaching some internal documentation for my hack for historical

purposes.

Thank you very much for your advice!

Helio Machado <0x2b3bfa0@gmail.com> writes:

Exciting, good luck on the journey. Importers are decoupled from

build systems, so I'm curious what structural changes are imposed.

Feel free to drop by the #guix IRC channel on Freenode for

up-to-the-minute feedback. :-)

Thanks a lot for diving into this!

unarchive 43872

dear fellow hackers,

i'm wondering what happened to the go-ethereum package.

i'm new to guix. i came over from nixos to package the bee client of swarm (https://www.ethswarm.org/).i made a package/service for it on nixos, but the module/service handling there is not flexible enough, and i got discouraged by the seemingly pointless struggle with it.

go-ethereum is a dependency of bee, or more specifically, the clef binary of the go-ethereum project.

this issue is marked CLOSED, but i don't see go-ethereum anywhere in the repo, even though the go importer seems to have been merged.

is there something i can do to help? shall i test this package on guix HEAD? or shall i just wait patiently?

any guidance is appreciated,

- attila

PGP: 5D5F 45C7 DFCD 0A39

Hi,

Thanks for your interest.

On Sun, 29 Aug 2021 at 18:43, Attila Lendvai <attila@lendvai.name> wrote:

As Marius wrote when closing the patch submission:

The issue is marked closed because it was an incorrect way to package

it. The Go importer is indeed merged. Maybe, you could give a try

via this way.

From my opinion, you would get more answers asking on the mailing

guix-devel or on the IRC channel #guix than by unarchiving this "old"

submission. :-)

All the best,

simon