Update installing-geth.md: Include Gentoo installation instructions #30450
Conversation
❌ Deploy Preview for geth-website failed. Why did it fail? →Built without sensitive environment variables
|
| @@ -143,6 +143,22 @@ sudo pacman -Sy | |||
|
|
|||
| When the node is started again, Geth will automatically use all the data from the previous version and sync the blocks that were missed while the node was offline. | |||
|
|
|||
| ### Gentoo via Portage {#gentoo-via-portage} | |||
|
|
|||
| Geth is included in the Gentoo repository as [`net-p2p/go-ethereum`](https://packages.gentoo.org/packages/net-p2p/go-ethereum). It can be installed by running: | |||
There was a problem hiding this comment.
Is this maintained by you personally, @SamWilsn ?
IMO we should integrate it into our CI pipeline if we have it here -- no offense meant to you, but we should not rely on specific individuals pushing packages years into the future.
There was a problem hiding this comment.
Is this maintained by you personally, @SamWilsn ?
I am the current maintainer, yes. It has been in the Gentoo repository for much longer than that, however. Note that this is the official Gentoo repository, and is not something like a PPA or the AUR.
IMO we should integrate it into our CI pipeline if we have it here
I'd be happy to investigate automation if there's a chance of merging it. Essentially this would entail copying a file, updating the URL, running a build, and opening a pull request.
How is this implemented for Arch Linux?
There was a problem hiding this comment.
We don't maintain the ArchLinux package, it's done by a community member.
There was a problem hiding this comment.
Ah.
Well as far as automation goes, I believe it would go in ci.go? The process for 1.14.9 would look something like:
- Clone
gentoo/gentoo. - Copy
net-p2p/go-ethereum/go-ethereum-1.14.8.ebuildtonet-p2p/go-ethereum/go-ethereum-1.14.9.ebuild. - Update the source tarball filename (
LONG_VERSION). - Run a test build with and without
USE=devtools. I imagine this would use docker. - Commit the new ebuild file.
- Push it and create a pull request.
Should I go ahead and build all of that, or can I continue to do it by hand (with the assumption it'll get removed from the documentation if the package gets out of date)?
There was a problem hiding this comment.
I don't think we want to automate this in our pipeline. ci.go is the build script that creates binaries. We do have some automation in there for Debian/Ubuntu as well. But it's just about generating packaging files.
There was a problem hiding this comment.
I see three options for moving this PR forward:
- Close this pull request without merging, even though neither Arch nor FreeBSD have automation (I'm fine with this, but I'd like geth to be explicit about it.)
- Merge the pull request as is (suffers from single point of failure: me.)
- I build automation outside the go-ethereum repository (same single point of failure concern.)
How would you like to proceed?
|
Todo: discuss on triage how we want to handle packages which are not under our control. Should we publicize them in our repo, or should we not? |
No description provided.