1 |
On Mon, Sep 23, 2019 at 06:36:49PM -0500, William Hubbs wrote: |
2 |
> This eclass adds a src_unpack function that supports the EGO_VENDOR |
3 |
> variable for vendoring modules. |
4 |
> --- |
5 |
> eclass/go-module-vendor.eclass | 124 +++++++++++++++++++++++++++++++++ |
6 |
> 1 file changed, 124 insertions(+) |
7 |
> create mode 100644 eclass/go-module-vendor.eclass |
8 |
> |
9 |
> diff --git a/eclass/go-module-vendor.eclass b/eclass/go-module-vendor.eclass |
10 |
> new file mode 100644 |
11 |
> index 00000000000..ceb362d89ba |
12 |
> --- /dev/null |
13 |
> +++ b/eclass/go-module-vendor.eclass |
14 |
> @@ -0,0 +1,124 @@ |
15 |
> +# Copyright 2019 gentoo authors |
16 |
> +# Distributed under the terms of the GNU General Public License v2 |
17 |
> + |
18 |
> +# @ECLASS: go-module-vendor.eclass |
19 |
> +# @MAINTAINER: |
20 |
> +# William Hubbs <williamh@g.o> |
21 |
> +# @SUPPORTED_EAPIS: 7 |
22 |
> +# @BLURB: Eclass for building software written in the go |
23 |
> +# programming language that uses go modules and does not vendor. |
24 |
> +# @DESCRIPTION: |
25 |
> +# This eclass provides a src_unpack function which supports vendoring |
26 |
> +# dependencies for software written in the go programming language that |
27 |
> +# uses go modules. |
28 |
> +# |
29 |
> +# You will know the software you are packaging uses modules because |
30 |
> +# it will have files named go.sum and go.mod in its top-level source |
31 |
> +# directory. If it does not have these files, use the golang-* eclasses. |
32 |
> +# |
33 |
> +# If there is also a directory named vendor in the top level source directory |
34 |
> +# of your package, use the golang-module eclass instead of this one. |
35 |
> +# |
36 |
> +# This eclass provides a src_unpack function which unpacks the |
37 |
> +# first tarball mentioned in SRC_URI to ${S} and unpacks any modules |
38 |
> +# mentioned in EGO_VENDOR to ${S}/vendor. |
39 |
> +# |
40 |
> +# Please note that this eclass currently handles only tarballs |
41 |
> +# (.tar.gz), but support for more formats may be added in the future. |
42 |
> +# |
43 |
> +# Since Go programs are statically linked, it is important that your ebuild's |
44 |
> +# LICENSE= setting includes the licenses of all statically linked |
45 |
> +# dependencies. So please make sure it is accurate. |
46 |
> +# |
47 |
> +# @EXAMPLE: |
48 |
> +# |
49 |
> +# @CODE |
50 |
> +# inherit go-module-vendor |
51 |
> +# |
52 |
> +# EGO_VENDOR=( |
53 |
> +# "github.com/xenolf/lego 6cac0ea7d8b28c889f709ec7fa92e92b82f490dd" |
54 |
> +# "golang.org/x/crypto 453249f01cfeb54c3d549ddb75ff152ca243f9d8 github.com/golang/crypto" |
55 |
> +# ) |
56 |
> +# |
57 |
> +# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz -> ${P}.tar.gz |
58 |
> +# $(go-module-vendor_get_vendor_uri)" |
59 |
> +# @CODE |
60 |
> + |
61 |
> +inherit go-module |
62 |
> + |
63 |
> +case ${EAPI:-0} in |
64 |
> + 7) ;; |
65 |
> + *) die "${ECLASS} API in EAPI ${EAPI} not yet established." |
66 |
> +esac |
67 |
> + |
68 |
> +if [[ -z ${_GO_MODULE_VENDOR} ]]; then |
69 |
> + |
70 |
> +_GO_MODULE_VENDOR=1 |
71 |
> + |
72 |
> +EXPORT_FUNCTIONS src_unpack |
73 |
> + |
74 |
> +# @ECLASS-VARIABLE: EGO_VENDOR |
75 |
> +# @REQUIRED |
76 |
> +# @DESCRIPTION: |
77 |
> +# This variable contains a list of vendored packages. |
78 |
> +# The items of this array are strings that contain the |
79 |
> +# import path and the git commit hash for a vendored package. |
80 |
> +# If the import path does not start with github.com, the third argument |
81 |
> +# can be used to point to a github repository. |
82 |
> + |
83 |
> +# @FUNCTION: go-module-vendor_get_vendor_uri |
84 |
> +# @DESCRIPTION: |
85 |
> +# Convert the information in EGO_VENDOR to a format suitable for |
86 |
> +# SRC_URI. |
87 |
> +# A call to this function should be added to SRC_URI in your ebuild. |
88 |
> +go-module-vendor_get_vendor_uri() { |
89 |
> + local hash import line repo |
90 |
> + for line in "${EGO_VENDOR[@]}"; do |
91 |
> + read -r import hash repo _ <<< "${line}" |
92 |
> + if [[ -n ${repo} ]]; then |
93 |
> + echo "https://${repo}/archive/${hash}.tar.gz -> ${repo//\//-}-${hash}.tar.gz" |
94 |
> + else |
95 |
> + echo "https://${import}/archive/${hash}.tar.gz -> ${import//\//-}-${hash}.tar.gz" |
96 |
> + fi |
97 |
> + done |
98 |
> +} |
99 |
> + |
100 |
> +# @FUNCTION: go-module-vendor_src_unpack |
101 |
> +# @DESCRIPTION: |
102 |
> +# Extract all archives in ${a} which are not nentioned in ${EGO_VENDOR} |
103 |
> +# to their usual locations then extract all archives mentioned in |
104 |
> +# ${EGO_VENDOR} to ${S}/vendor. |
105 |
> +go-module-vendor_src_unpack() { |
106 |
> + local f hash import line repo tarball vendor_uri |
107 |
> + if [[ -z "${EGO_VENDOR}" ]]; then |
108 |
> + die "EGO_VENDOR is not defined" |
109 |
> + fi |
110 |
> + |
111 |
> + vendor_uri="$(go-module-vendor_get_vendor_uri)" |
112 |
> + for f in $A; do |
113 |
> + [[ $vendor_uri == *"$f"* ]] && continue |
114 |
> + unpack $f |
115 |
> + done |
116 |
> + |
117 |
> + if [[ -d "${S}/vendor" ]]; then |
118 |
> + eerror "Upstream for ${P}.ebuild vendors dependencies." |
119 |
> + die "This ebuild should inherit go-module.eclass" |
120 |
> + fi |
121 |
|
122 |
All, |
123 |
|
124 |
I want to talk about the if block just above where I am writing. |
125 |
|
126 |
If the vendor directory exists after the sources are unpacked, the idea |
127 |
is that upstream is vendoring their dependencies and we probably don't |
128 |
want to mess with the contents of the vendor directory in that case. |
129 |
|
130 |
Mgorny, you suggested that there might be a valid use case for being |
131 |
able to insert our own dependencies even when upstream bundles them for |
132 |
security. Something like that is an easy enough change (deleting the if |
133 |
block), but I want to know more about whether this is a strong case for |
134 |
it. My thought is that if the issue is reported to upstream, they should |
135 |
do a new release after updating their vendored dependencies, so this is |
136 |
more an upstream thing. |
137 |
|
138 |
Thoughts? Is there a strong enough use case for messing with the bundled |
139 |
dependencies ourself? |
140 |
|
141 |
Thanks, |
142 |
|
143 |
William |