Looks good, will accept. I wanted to discuss one item, mostly for my edification. The reason there have been two calls to %setup is to ensure that the prepared contents of vendor.tar.gz unconditionally overwrite contents of vendor/ that might be present in the application tarball.
Whether vendor/ should be committed is an individual decision by upstream projects, but I have encountered several Go projects that have committed outdated or incomplete vendor/ directories that cause builds in the offline OBS environment to fail.
For my edification, is it certain that %autosetup -a1 has this behavior? I'll start using that in all Go packaging if so.
@jfkw. Absolutely, @jengelh did the change but I understand it as I use it always now (no more %setup), it is functionally indifferent so if it worked before it will work after.
Looks good, will accept. I wanted to discuss one item, mostly for my edification. The reason there have been two calls to %setup is to ensure that the prepared contents of vendor.tar.gz unconditionally overwrite contents of vendor/ that might be present in the application tarball.
Whether vendor/ should be committed is an individual decision by upstream projects, but I have encountered several Go projects that have committed outdated or incomplete vendor/ directories that cause builds in the offline OBS environment to fail.
For my edification, is it certain that %autosetup -a1 has this behavior? I'll start using that in all Go packaging if so.
@jfkw. Absolutely, @jengelh did the change but I understand it as I use it always now (no more %setup), it is functionally indifferent so if it worked before it will work after.
Also @jfkw put "this should be in Staging:E" in submit request description