stack assumes tar is GNU tar, but that's not always true

[bonds]

I tried installing GHC using stack, but I got an error:

~ ❯❯❯ stack setup                                   Sat Jun 18 23:14:16 PDT 2016
Run from outside a project, using implicit global project config
Using resolver: nightly-2016-06-19 from implicit global project's config file: /home/scott/.stack/global-project/stack.yaml
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Already downloaded.                
Running /bin/tar xf /home/scott/.stack/programs/x86_64-openbsd/ghc-8.0.1.tar.xz in directory /tmp/stack-setup30131/ exited with ExitFailure 1


tar: input compressed with xz

Unpacking GHC into /tmp/stack-setup30131/ ...⏎                                  

OpenBSD's tar doesn't support xz. I happened to have the GNU tar packages installed, its binary is named gtar on OpenBSD, so I worked around the issue by symlinking gtar as tar. Would be neat if stack looked for gtar instead of tar on OpenBSD and told the user to go install gtar if they haven't. I won't be offended if you have higher priority stuff to do though, just thought I'd throw this out there, just in case. :)

[borsboom]

In #416 (comment) (which lists the requirements before Stack supports OpenBSD), I suggested having stack setup use bzcat/xzcat directly and piping the output to tar rather than relying on GNU tar's behaviour. Does that seem like a reasonable alternative?

[bonds]

That sounds reasonable, but neither bzcat nor xzcat (nor GNU tar) are installed by default on OpenBSD machines, so an error message telling the user to install xz would probably still be helpful to some folks.

[Blaisorblade]

That sounds reasonable, but neither bzcat nor xzcat (nor GNU tar) are installed by default on OpenBSD machines, so an error message telling the user to install xz would probably still be helpful to some folks.

That message should already be there—Stack looks up xz if needed by the archive being installed, and reports missing deps with "The following executables are missing and must be installed".

It seems looking for gtar would be easy though, and Stack already does the same for make. One could replace, in

stack/src/Stack/Setup.hs

Line 801 in 8e61e9a

zipTool' <-

,

        <*> (checkDependency "gmake" <|> checkDependency "make")
        <*> checkDependency "tar"

with

        <*> (checkDependency "gmake" <|> checkDependency "make")
        <*> (checkDependency "gtar" <|> checkDependency "tar")

The g prefix is also used on OS X by Homebrew so there's a precedent (though OS X's bsdtar does support xz).

However, this would silently fallback to tar even on OpenBSD.

Using a pipe would be more robust but a bit trickier (that is, not a 5-minute job).
EDIT: on opening pipes, I guess one should "just" study https://www.schoolofhaskell.com/user/snoyberg/library-documentation/data-conduit-process#pipes-and-signals and find any updates.

[mgsloan]

Makes sense to me!

[Blaisorblade]

I looked at the code and this was easy. I learned I have easy access to both the platform and the archive type, so I ended up doing something slightly different in 90ecd0c, and closer to what @bonds described—on OpenBSD I require gtar and not attempt tar. But I do that only for xz archives (I could drop that) since IIUC OpenBSD tar supports bzip2 and gzip. If gtar is not found, it should give as error "The following executables are missing and must be installed: gtar".
@bonds Would you be interested in testing the workaround I described?

Right now I'm defaulting to gtar also elsewhere (for testing) but I'll probably revert that part.

[bonds]

OpenBSD tar does support bzip2 and gzip, but those require params (-j and -z) or you get an error:

~/s/winot (scott|✚3) ❯❯❯ stack setup                Mon Aug  8 08:47:26 PDT 2016
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Downloaded ghc-7.8.3.                                     
Running /bin/tar xf /home/scott/.stack/programs/x86_64-openbsd/ghc-7.8.3.tar.bz2 in directory /tmp/stack-setup11641/ exited with ExitFailure 1


tar: input compressed with bzip2; use the -j option to decompress it

Unpacking GHC into /tmp/stack-setup11641/ ...⏎                                  ~/s/winot (scott|✚3) ❯❯❯                            Mon Aug  8 08:49:12 PDT 2016

@Blaisorblade I'll try out the '2283-openbsd-hack' branch and let you know how it goes.

[bonds]

Verified '2283-openbsd-hack' works as expected on OpenBSD, that is to say, it handles xz compressed archives now.

Without gtar installed:

~/s/winot (scott|✚3) ❯❯❯ /home/scott/src/stack/.stack-work/install/x86_64-openbsd/lts-6.0/7.10.3/bin/stack setup
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Already downloaded.                
The following executables are missing and must be installed: gtar

With gtar installed:

~/s/winot (scott|✚3) ❯❯❯ /home/scott/src/stack/.stack-work/install/x86_64-openbsd/lts-6.0/7.10.3/bin/stack setup
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Already downloaded.                
Installing GHC ...^Cuser interrupt      

[Blaisorblade]

@bonds Good to hear!
I could also pass j and z to tar for extra portability (thanks for the reminder, I thought about it but then forgot) or always require gtar on OpenBSD—your choice I'd say.

[bonds]

If you're up for it, I suggest pass j and z, that way gtar isn't required when it wouldn't otherwise be needed.

[Blaisorblade]

If you're up for it, I suggest pass j and z, that way gtar isn't required when it wouldn't otherwise be needed.

Agreed and done (in 0ae5411), PR in #2456. I'm using tar jxf/tar zxf, http://man.openbsd.org/tar.1 suggests it will work.
Beware I rebased and force-pushed the branch, so git pull won't do the right thing!

[mgsloan]

The PR has been merged, so I think this is fixed! Good stuff!

[Blaisorblade]

As long as nobody objects to requiring gtar, this is indeed fixed.

I might be a wimp for not trying to use piping, but since you can get that wrong (signals/threading/exceptions/whatnot) I also feel I shouldn't try unless I'm an expert in getting that right ;-).

[mgsloan]

Seems reasonable to require that on openbsd. Seems fine to not use piping too!