Re: [gentoo-dev] [PATCH 1/3] go-module.eclass: introduce new eclass to handle go modules

[Michał Górny]

On Thu, 2019-09-12 at 11:39 -0500, William Hubbs wrote:
> On Thu, Sep 12, 2019 at 05:39:42AM +0000, Michał Górny wrote:
> > Dnia September 11, 2019 11:11:15 PM UTC, William Hubbs <williamh@g.o> napisał(a):
> > > You are right, and currently I quietly ignore your vendor tarball if
> > > upstream
> > > vendors the dependencies also. I could change this to generate a
> > > warning
> > > or die and force you to fix the ebuild, but that would not be possible
> > > if I follow your suggestion because I would not be able to tell whether
> > > the vendored dependencies came from us or upstream.
> >
> > Why would anyone create a vendor tarball if things work without it? That makes no sense. Also adding unused archives to SRC_URI is a QA violation.
>
> All the more reason to not have the vendor tarball overwrite the vendor
> directory upstream. I will show you when I update the eclass.

If there is a vendor directory, then you should not have custom vendor
tarball to override it in the first place.  If you have the tarball,
the eclass should explode and tell the developer he's doing silly things
and needs to stop, not silently pretend everything is fine and surprise
people by coincidentally choosing not to do anything.

>
> > > Also, another concern about your suggestion is the  --transform switch
> > > that would have to be added to the  tar command people use to create
> > > the
> > > vendor tarball, something like:
> > >
> > > tar -acvf package-version-vendor.tar.gz
> > > --transform='s#^vendor#package-version-vendor#' vendor
> > >
> > > You suggested that a maintainer could create a new tarball and build on
> > > top of it. I guess you mean  don't use upstream's tarball if they don't
> > > vendor and create my own tarball and add the vendor directory to it.
> > > I'm
> > > against that option because  I don't feel that we should manually
> > > tinker
> > > with upstream tarballs. That opens a pretty big can of worms imo.
> >
> > No. I suggested that rather than adding another git clone and checking out a tag (which sooner or later would mean someone forgetting and using master instead), you could unpack the same archive you're going to use in the ebuild.
>
> Ok, I am really not following you, so let's talk about this in the
> context of an example.
>
> Look at app-misc/spire and tell me how you would do it differently.
>

ebuild spire-0.8.1.ebuild fetch
tar -xf ${DISTDIR}/spire-0.8.1.tar.gz
cd spire-0.8.1/
go mod vendor
cd ../
tar -cf spire-0.8.1-vendor.tar spire-0.8.1/vendor

Now you don't need special src_prepare() to unpack it.

-- 
Best regards,
Michał Górny