1 |
On Sat, Feb 26, 2022 at 08:25:59AM +0100, Michał Górny wrote: |
2 |
> On Fri, 2022-02-25 at 20:50 -0600, William Hubbs wrote: |
3 |
> > EGO_SUM can be thousands of lines long in ebuilds, and it leads to |
4 |
> > creating Manifest files that are thousands of lines long. |
5 |
> > It has been determined that vendor tarballs are a better solution if |
6 |
> > upstream doesn't vendor their dependencies. |
7 |
> > |
8 |
> > Also, call the ego helper function instead of calling go directly. |
9 |
> > |
10 |
> > Signed-off-by: William Hubbs <williamh@g.o> |
11 |
> > --- |
12 |
> > eclass/go-module.eclass | 140 ++++++++++------------------------------ |
13 |
> > 1 file changed, 34 insertions(+), 106 deletions(-) |
14 |
> > |
15 |
> > diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass |
16 |
> > index 66fe52c9ad7..7f0d766f444 100644 |
17 |
> > --- a/eclass/go-module.eclass |
18 |
> > +++ b/eclass/go-module.eclass |
19 |
> > @@ -25,8 +25,18 @@ |
20 |
> > # |
21 |
> > # If the software has a directory named vendor in its |
22 |
> > # top level directory, the only thing you need to do is inherit the |
23 |
> > -# eclass. Otherwise, you need to also populate |
24 |
> > -# EGO_SUM and call go-module_set_globals as discussed below. |
25 |
> > +# eclass. If it doesn't, you need to also create a vendor tarball and |
26 |
> > +# host it somewhere, for example in your dev space. |
27 |
> > +# |
28 |
> > +# Here are the commands to create a vendor tarball. |
29 |
> > +# |
30 |
> > +# @CODE |
31 |
> > +# |
32 |
> > +# $ cd /path/to/project |
33 |
> > +# $ go mod vendor |
34 |
> > +# $ tar -acf project-1.0.tar.xz vendor |
35 |
> |
36 |
> Why not 'cd ..' first and create a tarball that doesn't require custom |
37 |
> src_unpack()? Also, shouldn't the name be 'project-1.0-vendor.tar'? |
38 |
> Also, you're mising -J. |
39 |
|
40 |
Using -a and -J together doesn't make sense since -a uses the suffix on |
41 |
the file name to determine which compressor to use. |
42 |
|
43 |
If I change the instructions as you suggest to re-package upstream's |
44 |
tarball the name wouldn't need the -vendor suffix since the tarball would be a |
45 |
fork, but I'm not asking people to fork and repackage upstream's tarballs, just |
46 |
the vendor folder. Fortunately, there is no reason to fork since it is very |
47 |
easy to package the vendor folder with Go's tools. |
48 |
|
49 |
To move the unpacked vendor folder to the right place, I have two |
50 |
choices, src_unpack and src_prepare. Since we already have a custom |
51 |
src_unpack, it is less invasive to do this there. If I use src_prepare, |
52 |
it would force me to bump the eclass, which I'm not interested in doing. |
53 |
|
54 |
William |