1 |
On 9/23/19 5:30 PM, William Hubbs wrote: |
2 |
>> +# @FUNCTION: go-module-vendor_src_unpack |
3 |
>> +# @DESCRIPTION: |
4 |
>> +# Extract all archives in ${a} which are not nentioned in ${EGO_VENDOR} |
5 |
>> +# to their usual locations then extract all archives mentioned in |
6 |
>> +# ${EGO_VENDOR} to ${S}/vendor. |
7 |
>> +go-module-vendor_src_unpack() { |
8 |
>> + local f hash import line repo tarball vendor_uri |
9 |
>> + if [[ -z "${EGO_VENDOR}" ]]; then |
10 |
>> + die "EGO_VENDOR is not defined" |
11 |
>> + fi |
12 |
>> + |
13 |
>> + vendor_uri="$(go-module-vendor_get_vendor_uri)" |
14 |
>> + for f in $A; do |
15 |
>> + [[ $vendor_uri == *"$f"* ]] && continue |
16 |
>> + unpack $f |
17 |
>> + done |
18 |
>> + |
19 |
>> + if [[ -d "${S}/vendor" ]]; then |
20 |
>> + eerror "Upstream for ${P}.ebuild vendors dependencies." |
21 |
>> + die "This ebuild should inherit go-module.eclass" |
22 |
>> + fi |
23 |
> |
24 |
> All, |
25 |
> |
26 |
> I want to talk about the if block just above where I am writing. |
27 |
> |
28 |
> If the vendor directory exists after the sources are unpacked, the idea |
29 |
> is that upstream is vendoring their dependencies and we probably don't |
30 |
> want to mess with the contents of the vendor directory in that case. |
31 |
> |
32 |
> Mgorny, you suggested that there might be a valid use case for being |
33 |
> able to insert our own dependencies even when upstream bundles them for |
34 |
> security. Something like that is an easy enough change (deleting the if |
35 |
> block), but I want to know more about whether this is a strong case for |
36 |
> it. My thought is that if the issue is reported to upstream, they should |
37 |
> do a new release after updating their vendored dependencies, so this is |
38 |
> more an upstream thing. |
39 |
> |
40 |
> Thoughts? Is there a strong enough use case for messing with the bundled |
41 |
> dependencies ourself? |
42 |
|
43 |
If you feel like it would add unnecessary complexity, then it's probably |
44 |
fine to leave that case unsupported. The worst case is that ebuild |
45 |
maintainers will have to copy and modify the eclass function. |
46 |
-- |
47 |
Thanks, |
48 |
Zac |