Re: On the state of 'tar'

Oh good point. I’ve had problems with static linking. The reason I didn’t bundle libarchive is that it requires a config.h with macros that are generated with ./configure… It would certainly be nice to have partially static linking via cabal! And yes I agree, I’d use it if it were broad enough

On Apr 7, 2020, at 2:56 PM, hasufell wrote:

The problem with libarchive and bindings in general is portability.

A half way out of this would be to allow cabal/ghc to do partially static linking. But that's probably not gonna happen anytime soon.

Alternatively... have a +static cabal flag that builds from bundled source? Ideas...

But I think a native 'tar' implementation is still worthwhile.

On 07/04/2020 21:35, Vanessa McHale wrote:

...

FWIW, the tar format is a mess, which is part of why I chose to bind to libarchive (with all the difficulties) instead of writing my own library. There’s a nice post here: https://www.cyphar.com/blog/post/20190121-ociv2-images-i-tar

There’s also archive-sig (http://hackage.haskell.org/package/archive-sig) which tries to be a “common interface” via backpack and has implementations such as archive-tar-bytestring (http://hackage.haskell.org/package/archive-tar-bytestring) that can be swapped out with libarchive/tar proper so you don’t need to commit to any one library.

Cheers, Vanessa McHale

...

On Apr 7, 2020, at 11:50 AM, hasufell mailto:hasufell@posteo.de>> wrote:

Friends,

'tar' [0][1] is an excellent native haskell implementation of the tar format. However, there are currently a lot of unattended issues:

* unicode filepaths broken due to Char8 use [2] * executable bits handled improperly [3] * no support for long filepath extension [4][5] * doesn't handle hardlinks properly [6] * handles symbolic links too strictly [7]

Most of these issues are 2 to 4 years old, some of them have PRs that have never been reviewed.

'tar' fails to unpack our own ghc bindists even [4]. I consider it, in this state, too unreliable for production use. Since it is in the 'haskell' namespace on github and probably the first hit on hackage, this needs to be improved quickly, IMO.

Users currently can use tar-bytestring [8] (no windows support) or libarchive [9] (not a native implementation), but 'tar' should ultimately be fixed and maintained properly.

-- [0] https://hackage.haskell.org/package/tar https://hackage.haskell.org/package/tar [1] https://github.com/haskell/tar https://github.com/haskell/tar [2] https://github.com/haskell/tar/issues/6 https://github.com/haskell/tar/issues/6 [3] https://github.com/haskell/tar/issues/25 https://github.com/haskell/tar/issues/25 [4] https://github.com/haskell/tar/issues/49 https://github.com/haskell/tar/issues/49 [5] https://github.com/haskell/tar/issues/27 https://github.com/haskell/tar/issues/27 [6] https://github.com/haskell/tar/issues/51 https://github.com/haskell/tar/issues/51 [7] https://github.com/haskell/tar/issues/32 https://github.com/haskell/tar/issues/32 [8] https://github.com/hasufell/tar-bytestring https://github.com/hasufell/tar-bytestring [9] https://hackage.haskell.org/package/libarchive https://hackage.haskell.org/package/libarchive --

Cheers, Julian _______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org mailto:Libraries@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries