public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Cc: William Hubbs <williamh@gentoo.org>
Subject: Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules
Date: Mon, 16 Sep 2019 20:05:50 +0200	[thread overview]
Message-ID: <9a93cbef4883b37a53ffa0003ca53a8deb393a96.camel@gentoo.org> (raw)
In-Reply-To: <20190916141719.12922-2-williamh@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 5311 bytes --]

On Mon, 2019-09-16 at 09:17 -0500, William Hubbs wrote:
> Signed-off-by: William Hubbs <williamh@gentoo.org>
> ---
>  eclass/go-module.eclass | 117 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 117 insertions(+)
>  create mode 100644 eclass/go-module.eclass
> 
> diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
> new file mode 100644
> index 00000000000..7e16ec4e95c
> --- /dev/null
> +++ b/eclass/go-module.eclass
> @@ -0,0 +1,117 @@
> +# Copyright 2019 gentoo authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: go-module.eclass
> +# @MAINTAINER:
> +# William Hubbs <williamh@gentoo.org>
> +# @SUPPORTED_EAPIS: 7
> +# @BLURB: basic eclass for building software written in the go
> +# programming language that uses go modules.
> +# @DESCRIPTION:
> +# This eclass provides some basic things needed by all software
> +# written in the go programming language that uses go modules.
> +#
> +# You will know the software you are packaging uses modules because
> +# it will have files named go.sum and go.mod in its top-level source
> +# directory. If it does not have these files, use the golang-* eclasses.

Please add a big fat warning around here somewhere that people need to
look through LICENSE files in all vendored modules, and list them
in LICENSE.  They also need to watch out for license conflicts.

> +#
> +# If the software you are packaging uses modules, the next question is
> +# whether it has a directory named "vendor" at the top-level of the source tree.
> +#
> +# If it doesn't, you need to create a tarball of what would be in the
> +# vendor directory and mirror it locally.
> +# If foo-1.0 is the name of your project and you have the tarball for it
> +# in your current directory,  this is done with the following commands:
> +#
> +# @CODE:
> +#
> +# tar -xf foo-1.0.tar.gz
> +# cd foo-1.0
> +# go mod vendor
> +# cd ..
> +# tar -acf foo-1.0-vendor.tar.gz foo-1.0/vendor
> +#
> +# @CODE:
> +
> +# If we uncomment src_prepare below, the last two lines in the above
> +# code block are reduced to one:
> +#
> +# @CODE:
> +#
> +# tar -acf foo-1.0-vendor.tar.gz vendor
> +#
> +# @CODE:
> +
> +case ${EAPI:-0} in
> +	7) ;;
> +	*) die "${ECLASS} API in EAPI ${EAPI} not yet established."
> +esac
> +
> +if [[ -z ${_GO_MODULE} ]]; then
> +
> +_GO_MODULE=1
> +
> +BDEPEND=">=dev-lang/go-1.12"
> +
> +# The following go flags should be used for all go builds.
> +# -mod=vendor stopps downloading of dependencies from the internet.
> +# -v prints the names of packages as they are compiled
> +# -x prints commands as they are executed
> +export GOFLAGS="-mod=vendor -v -x"
> +
> +# Do not complain about CFLAGS etc since go projects do not use them.
> +QA_FLAGS_IGNORED='.*'
> +
> +# Go packages should not be stripped with strip(1).
> +RESTRICT="strip"
> +
> +# EXPORT_FUNCTIONS src_prepare pkg_postinst
> + EXPORT_FUNCTIONS pkg_postinst
> +
> +# @FUNCTION: go-module_src_prepare
> +# @DESCRIPTION:
> +# Run a default src_prepare then move our provided vendor directory to
> +# the appropriate spot if upstream doesn't provide a vendor directory.
> +#
> +# This is commented out because I want to see where the discussion on
> +# the ml leads.
> +# Commenting it out and following the above instructions means that you
> +# are forced to manually re-tar the vendored dependencies for every
> +# version bump.
> +# Using the previous method, it would be possible to decide if you need
> +# to do this by comparing the contents of go.mod in the previous and new
> +# version.
> +# Also, note that we can generate a qa warning if a maintainer forgets
> +# to drop the vendor tarball and upstream starts vendoring.
> +# go-module_src_prepare() {
> +#	default
> +#	# If upstream vendors the dependencies and we provide a vendor
> +#	# tarball, generate a qa warning.
> +#	if [[ -d vendor ]] && [[ -d ../vendor ]] ; then
> +#		eqawarn "This package's upstream source includes a vendor
> +#		eqawarn "directory and the maintainer provides a vendor tarball."
> +#		eqawarn "Please report this on https://bugs.gentoo.org"

Why aren't you making it fatal?

> +#	fi
> +#	# Use the upstream provided vendor directory if it exists.
> +#	[[ -d vendor ]] && return
> +#	# If we are not providing a mirror of a vendor directory we created
> +#	# manually, return since there may be nothing to vendor.
> +#	[[ ! -d ../vendor ]] && return
> +#	# At this point, we know we are providing a vendor mirror.
> +#	mv ../vendor . || die "Unable to move ../vendor directory"
> +# }
> +
> +# @FUNCTION: go-module_pkg_postinst
> +# @DESCRIPTION:
> +# Display a warning about security updates for Go programs.
> +go-module_pkg_postinst() {
> +	ewarn "${PN} is written in the Go programming language."
> +	ewarn "Since this language is statically linked, security"
> +	ewarn "updates will be handled in individual packages and will be"
> +	ewarn "difficult for us to track as a distribution."
> +	ewarn "For this reason, please update any go packages asap when new"
> +	ewarn "versions enter the tree or go stable if you are running the"
> +	ewarn "stable tree."
> +}
> +
> +fi

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

  parent reply	other threads:[~2019-09-16 18:05 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-16 14:17 [gentoo-dev] [PATCH 0/1] introduce new eclass to handle go modules (round 3) William Hubbs
2019-09-16 14:17 ` [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules William Hubbs
2019-09-16 17:40   ` William Hubbs
2019-09-16 17:48   ` Zac Medico
2019-09-16 18:26     ` William Hubbs
2019-09-16 19:50       ` Zac Medico
2019-09-16 18:01   ` Zac Medico
2019-09-16 18:35     ` William Hubbs
2019-09-16 18:50       ` Zac Medico
2019-09-16 22:00         ` William Hubbs
2019-09-17  5:36           ` Michał Górny
2019-09-17 14:10             ` William Hubbs
2019-09-17 17:40               ` Zac Medico
2019-09-16 18:05   ` Michał Górny [this message]
2019-09-16 18:46     ` William Hubbs
2019-09-16 19:19       ` Michał Górny
2019-09-18 17:49   ` Michael Orlitzky
2019-09-18 18:04     ` Alec Warner
2019-09-18 19:15       ` Michael Orlitzky
2019-09-18 19:33         ` Alec Warner
2019-09-19  1:09           ` Michael Orlitzky
2019-09-18 19:28       ` Zac Medico
2019-09-18 21:11         ` William Hubbs
  -- strict thread matches above, loose matches on Subject: below --
2019-09-18 20:26 [gentoo-dev] [PATCH 0/1] introduce an eclass to handle go modules (round 5) William Hubbs
2019-09-18 20:26 ` [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules William Hubbs
2019-09-18 20:29   ` Michał Górny
2019-09-18 21:28     ` William Hubbs
2019-09-19  1:02       ` Michael Orlitzky
2019-09-16 22:47 [gentoo-dev] [PATCH 0/1] introduce new eclass to handle go modules (round 4) William Hubbs
2019-09-16 22:47 ` [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules William Hubbs
2019-09-13 15:49 [gentoo-dev] [PATCH 0/1] Introduce new eclass to handle go modules (round 2) William Hubbs
2019-09-13 15:49 ` [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules William Hubbs
2019-09-13 15:58   ` William Hubbs

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=9a93cbef4883b37a53ffa0003ca53a8deb393a96.camel@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=williamh@gentoo.org \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox