/go-overlay

This Portage overlay is for Go related ebuilds.

Primary LanguageShellGNU General Public License v2.0GPL-2.0

Go Overlay

Build Status

The Go Overlay is intended as a Portage collection of Go related ebuilds — mainly applications and tools written in Go. This repository offers Go packages that can be compiled in a reproducible way, without the need of recompiling wacky and obscure Go dependencies, or placing weird Go libraries inside your system GOROOT, and then ending up with a polluted and screwed up Go environment.

The primary reason why Go packages cannot be reproducibly built is because the import statement(which drives go get) does not contain sufficient information to identify which revision of a Go package it should fetch. Additionally, if the source code of a Go package changes in an incompatible way, there is no way for ebuild that consumes that import path to indicate that it does not want to blindly build against the latest revision of the code. Head over there for more information about reproducible builds in Go.

The Go Overlay main purpose is to create an easy way for the Go community to use Gentoo. This overlay strives to maintain a large set of Go packages as well as wide configuration options that users of Gentoo have come to expect.

User's Guide

Installing The Overlay

In order to manage overlays, the package app-portage/layman must be installed into your Gentoo environment:

emerge -av app-portage/layman

If the installation of layman was successfully completed, then you are ready to sync the content of this repository:

layman -a go-overlay

If you use eix you may need to execute:

eix-update

Updating The Overlay

Keep the overlay up to date with the following command:

layman -s go-overlay

Removing The Overlay

The process of removing this overlay from your Gentoo environment is quite straightforward:

layman -d go-overlay

Contributing

I welcome issue reports, feedbacks, and ebuild requests; I encourage you to use the issues list on GitHub to provide them.

Code contributions and bug fixes are welcome too, and I encourage the use of pull requests to discuss and review your ebuild code changes. Before proposing a large change, please discuss it by raising an issue.

Before You Begin

This overlay assumes that you have read, and properly understood, the Gentoo Developer Manual.

Code of Conduct

Help me to keep this overlay open and inclusive for everyone. Please, read and follow the Code of Conduct.

Making and Submitting Changes

To make the process of pull requests submission as seamless as possible, I ask for the following:

  1. Go ahead and fork this project and make your changes.

  2. When your code changes are ready, make sure to run repoman fix -d, repoman full -d, and repoman -vx full in the root of the repository to ensure that all the Gentoo's QA tests pass. This is necessary to assure nothing was accidentally broken by your changes; for the purpose this GitHub repository integrates Travis for Continuous Integration of repoman tests. I only take pull requests with passing repoman tests.

  3. Squash your commits into a single one with git rebase -i. It's okay to force update your pull request.

  4. Make sure your git commit messages are in the proper format to make reading history easier. Commit message should look like:

    [category/package-name] Short description
    
    Long description
    

    If you have questions about how to write the short / long descriptions, please read these blog articles: How to Write a Commit Message, 5 Useful Tips For A Better Commit Message. Both of them are excellent resources for learning how to write a well-crafted git commit message. If your commit references one or more GitHub issues, always end your commit message body with See #1234 or Fixes #1234 (replace 1234 with the desired GitHub issue ID).

  5. GPG signing your changes is a good idea, but not mandatory.

  6. Push your changes to your branch in your fork, and then submit a pull request agains this repository.

  7. Comment in the pull request when you are ready for the changes to be reviewed: PR ready for review.

At this point you are waiting for my feedbacks. I look at pull requests within few days. I may suggest some improvements or alternatives.