Re #13 Add partial support for pax header blocks

[mpilgrem]

Relies on the extended description of the pax interchange format at https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html.

The basic idea is that untarChunks already produces a stream of TarChunk that include the pax header block and pax extended header information, so applyPaxChunkHeaders consumes those TarChunk to produce TarChunk in which that information has been applied.

The pax keywords that are supported ('comment', 'gid', 'gname', 'linkpath', 'path', 'size', 'uid' and 'uname') are those that do not need any change to the Header data constructor. (In practice, the motivation for this was the path keyword and long directory names and filenames. See commercialhaskell/stack#6186 (comment))

Tested (in a limited way) for the 'path' keyword (see https://github.com/mpilgrem/tar-pax-conduit, where the code was first formulated). The other keywords are based on my reasoning only.

EDIT: I re-thought the API. untarChunks and untar now produce 'processed' TarChunks and untarChunksRaw and untarRaw behave like the previous version of untarChunks and untar. I assume that the Haskell PVP requires a major version bump because of the changed behaviour.

[snoyberg]

I'm not familiar with Pax myself, but this looks reasonable. My only suggestion would be adding a test case that includes a Pax-enabled tar file so we can confirm this is working as expected. But if you'd prefer that I merge as-is, I'm OK with that too, just let me know.

[mpilgrem]

@snoyberg, I'll aim to add a test. Separately, looking at the CI, would you be interested in another pull request that (a) moves CI onto GitHub Actions; and/or (b) tests against more recent versions of GHC (given what you explained at: https://www.snoyman.com/blog/babies-oss-maintenance/)?

[snoyberg]

yes and yes, thanks!

[snoyberg]

Just holding off merge because of the version number question.

[snoyberg]

Is there a reason this is now marked as a breaking change?

[mpilgrem]

My thinking was this: the Haskell PVP decision tree says a major bump is necessary if the 'behaviour' of any exported function changes. Here, untarChunks used to produce all ustar chunks (including those chunks used to specify pax header blocks and extended headers) and now it produces the chunks that remain after the application of any pax header blocks and extended headers. That seemed to me to be a 'change in behaviour' rather than just a 'bug fix', and is why I export untarChunksRaw (in order to preserve the previous behaviour for people who may actually have needed it).

[snoyberg]

I hear that. I'd interpret it differently. If there was a function that would previously fail on some input but now can successfully parse it, that's an improvement, not a breaking change. Maybe that isn't the case here. Either way, I'll defer to your judgement on whether a major version bump is warranted. Want me to merge and release?

[mpilgrem]

@snoyberg, if you could merge and release, that would be good.

[mpilgrem]

I have rebased on the master branch to reflect the new CI.

[snoyberg]

Uploaded tar-conduit 0.4.0 to Hackage.