On 9/23/19 5:30 PM, William Hubbs wrote:
>> +# @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?

If you feel like it would add unnecessary complexity, then it's probably
fine to leave that case unsupported. The worst case is that ebuild
maintainers will have to copy and modify the eclass function.
-- 
Thanks,
Zac