| 1 |
On 9/16/19 7:17 AM, William Hubbs wrote: |
| 2 |
> +# You will know the software you are packaging uses modules because |
| 3 |
> +# it will have files named go.sum and go.mod in its top-level source |
| 4 |
> +# directory. If it does not have these files, use the golang-* eclasses. |
| 5 |
> +# |
| 6 |
> +# If the software you are packaging uses modules, the next question is |
| 7 |
> +# whether it has a directory named "vendor" at the top-level of the source tree. |
| 8 |
> +# |
| 9 |
> +# If it doesn't, you need to create a tarball of what would be in the |
| 10 |
> +# vendor directory and mirror it locally. |
| 11 |
> +# If foo-1.0 is the name of your project and you have the tarball for it |
| 12 |
> +# in your current directory, this is done with the following commands: |
| 13 |
> +# |
| 14 |
> +# @CODE: |
| 15 |
> +# |
| 16 |
> +# tar -xf foo-1.0.tar.gz |
| 17 |
> +# cd foo-1.0 |
| 18 |
> +# go mod vendor |
| 19 |
> +# cd .. |
| 20 |
> +# tar -acf foo-1.0-vendor.tar.gz foo-1.0/vendor |
| 21 |
|
| 22 |
For packages that I maintain, I'd prefer to continue using EGO_VENDOR to |
| 23 |
even with packages using go.mod. I hope that this go-module.class will |
| 24 |
not preclude this sort of usage. For example, the latest go-tools ebuild |
| 25 |
uses EGO_VENDOR together with GOFLAGS="-mod=vendor": |
| 26 |
|
| 27 |
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8cc6d401139526e2f9a6dbadbd31f0ff2387705f |
| 28 |
-- |
| 29 |
Thanks, |
| 30 |
Zac |
Archives