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 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