Re: [gentoo-dev] [PATCH 2/2] go-module-vendor.eclass: new eclass for go modules that do not vendor

[William Hubbs <williamh@gentoo.org>]

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


On Mon, Sep 23, 2019 at 06:36:49PM -0500, William Hubbs wrote:
> This eclass adds a src_unpack function that supports the EGO_VENDOR
> variable for vendoring modules.
> ---
>  eclass/go-module-vendor.eclass | 124 +++++++++++++++++++++++++++++++++
>  1 file changed, 124 insertions(+)
>  create mode 100644 eclass/go-module-vendor.eclass
> 
> diff --git a/eclass/go-module-vendor.eclass b/eclass/go-module-vendor.eclass
> new file mode 100644
> index 00000000000..ceb362d89ba
> --- /dev/null
> +++ b/eclass/go-module-vendor.eclass
> @@ -0,0 +1,124 @@
> +# Copyright 2019 gentoo authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: go-module-vendor.eclass
> +# @MAINTAINER:
> +# William Hubbs <williamh@gentoo.org>
> +# @SUPPORTED_EAPIS: 7
> +# @BLURB: Eclass for building software written in the go
> +# programming language that uses go modules and does not vendor.
> +# @DESCRIPTION:
> +# This eclass provides a src_unpack function which supports vendoring
> +# dependencies for 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.
> +#
> +# If there is also a directory named vendor in the top level source directory
> +# of your package, use the golang-module eclass instead of this one.
> +#
> +# This eclass provides a src_unpack function which unpacks the
> +# first tarball mentioned in SRC_URI to ${S} and unpacks any modules
> +# mentioned in EGO_VENDOR to ${S}/vendor.
> +#
> +# Please note that this eclass currently handles only tarballs
> +# (.tar.gz), but support for more formats may be added in the future.
> +#
> +# Since Go programs are statically linked, it is important that your ebuild's
> +# LICENSE= setting includes the licenses of all statically linked
> +# dependencies. So please make sure it is accurate.
> +#
> +# @EXAMPLE:
> +#
> +# @CODE
> +# inherit go-module-vendor
> +#
> +# EGO_VENDOR=(
> +#	"github.com/xenolf/lego 6cac0ea7d8b28c889f709ec7fa92e92b82f490dd"
> +# "golang.org/x/crypto 453249f01cfeb54c3d549ddb75ff152ca243f9d8 github.com/golang/crypto"
> +# )
> +#
> +# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz -> ${P}.tar.gz
> +# $(go-module-vendor_get_vendor_uri)"
> +# @CODE
> +
> +inherit go-module
> +
> +case ${EAPI:-0} in
> +	7) ;;
> +	*) die "${ECLASS} API in EAPI ${EAPI} not yet established."
> +esac
> +
> +if [[ -z ${_GO_MODULE_VENDOR} ]]; then
> +
> +_GO_MODULE_VENDOR=1
> +
> +EXPORT_FUNCTIONS src_unpack
> +
> +# @ECLASS-VARIABLE: EGO_VENDOR
> +# @REQUIRED
> +# @DESCRIPTION:
> +# This variable contains a list of vendored packages.
> +# The items of this array are strings that contain the
> +# import path and the git commit hash for a vendored package.
> +# If the import path does not start with github.com, the third argument
> +# can be used to point to a github repository.
> +
> +# @FUNCTION: go-module-vendor_get_vendor_uri
> +# @DESCRIPTION:
> +# Convert the information in EGO_VENDOR to a format suitable for
> +# SRC_URI.
> +# A call to this function should be added to SRC_URI in your ebuild.
> +go-module-vendor_get_vendor_uri() {
> +	local hash import line repo
> +	for line in "${EGO_VENDOR[@]}"; do
> +		read -r import hash repo _ <<< "${line}"
> +		if [[ -n ${repo} ]]; then
> +			echo "https://${repo}/archive/${hash}.tar.gz -> ${repo//\//-}-${hash}.tar.gz"
> +		else
> +			echo "https://${import}/archive/${hash}.tar.gz -> ${import//\//-}-${hash}.tar.gz"
> +		fi
> +	done
> +}
> +
> +# @FUNCTION: go-module-vendor_src_unpack
> +# @DESCRIPTION:
> +# Extract all archives in ${a} which are not nentioned in ${EGO_VENDOR}
> +# to their usual locations then extract all archives mentioned in
> +# ${EGO_VENDOR} to ${S}/vendor.
> +go-module-vendor_src_unpack() {
> +	local f hash import line repo tarball vendor_uri
> +	if [[ -z "${EGO_VENDOR}" ]]; then
> +		die "EGO_VENDOR is not defined"
> +	fi
> +
> +	vendor_uri="$(go-module-vendor_get_vendor_uri)"
> +	for f in $A; do
> +		[[ $vendor_uri == *"$f"* ]] && continue
> +		unpack $f
> +	done
> +
> +	if [[ -d "${S}/vendor" ]]; then
> +		eerror "Upstream for ${P}.ebuild vendors dependencies."
> +		die "This ebuild should inherit go-module.eclass"
> +	fi

All,

I want to talk about the if block just above where I am writing.

If the vendor directory exists after the sources are unpacked, the idea
is that upstream is vendoring their dependencies and we probably don't
want to mess with the contents of the vendor directory in that case.

Mgorny, you suggested that there might be a valid use case for  being
able to insert our own dependencies even when upstream bundles them for
security. Something like that is an easy enough change (deleting the if
block), but I want to know more about whether this is a strong case for
it. My thought is that if the issue is reported to upstream, they should
do a new release after updating their vendored dependencies, so this is
more an upstream thing.

Thoughts? Is there a strong enough use case for messing with the bundled
dependencies ourself?

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]