On the state of 'tar'

[Oleg Grenrus]

Check `build-type: Configure` which eg `network` uses.

> On 7. Apr 2020, at 23.18, Vanessa McHale <vamchale at gmail.com> wrote:
> 
> 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 <hasufell at posteo.de> 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 <hasufell at posteo.de
>>>> <mailto:hasufell at 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
>>>> [1] https://github.com/haskell/tar
>>>> [2] https://github.com/haskell/tar/issues/6
>>>> [3] https://github.com/haskell/tar/issues/25
>>>> [4] https://github.com/haskell/tar/issues/49
>>>> [5] https://github.com/haskell/tar/issues/27
>>>> [6] https://github.com/haskell/tar/issues/51
>>>> [7] https://github.com/haskell/tar/issues/32
>>>> [8] https://github.com/hasufell/tar-bytestring
>>>> [9] https://hackage.haskell.org/package/libarchive
>>>> --
>>>> 
>>>> 
>>>> Cheers,
>>>> Julian
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org <mailto:Libraries at haskell.org>
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200408/1d582127/attachment.html>