Leo Famulari <leo@famulari.name> writes:

> On Tue, Jan 23, 2018 at 08:34:23PM +0000, Christopher Baines wrote:
>> 
>> Leo Famulari <leo@famulari.name> writes:
>> 
>> > On Tue, Jan 23, 2018 at 07:51:06PM +0000, Christopher Baines wrote:
>> >> Leo Famulari <leo@famulari.name> writes:
>> >> > On Mon, Jan 22, 2018 at 09:08:23PM +0000, Christopher Baines wrote:
>> >> >> * gnu/packages/golang.scm (go-github.com-jessevdk-go-flags): New variable.
>> >> >
>> >> >> +         (add-after 'unpack 'rename-archive
>> >> >> +           (lambda _
>> >> >> +             (rename-file
>> >> >> +              ,(string-append "src/github.com/jessevdk/go-flags-" version)
>> >> >> +              "src/github.com/jessevdk/go-flags")
>> >> >> +             #t)))))
>> >> >
>> >> > Should the go-build-system try to handle this automatically?
>> >> 
>> >> I believe this might be connected with what is in the source
>> >> tarball. Without this stage, the go-flags directory is called
>> >> go-flags-1.3.0, and this causes the build to fail [2].
>> >
>> > Oh right, Go expects you to use Git checkouts instead of release
>> > tarballs. I bet it works if you do that. That kind of tarball is
>> > automatically created by GitHub per tag, and can't be disabled.
>> >
>> >> I'm not sure about the wider context, but it would be good to handle
>> >> this automatically.
>> >
>> > So, I think the build system doesn't need to handle this case.
>> 
>> Ok, would it be more appropriate to use a git checkout, rather than a
>> tar archive for these packages then?
>
> Yeah, I bet you can avoid the rename-archive phases if you use a Git
> checkout.

I've done this now for all the packages, and sent a new set of patches.