New Hackage release

[elldritch]

It looks like the last version of this package published on Hackage is 0.5.1.1 published in August 2019. Are there plans to do a new release, especially since HEAD is now up to 0.7.0.0?

[Bodigrim]

Yes, but not immediately. There've been multiple changes recently and dust has not settled yet. You can accelerate things by acting as a beta tester:

• test your packages / products against tar-HEAD,
• build htar and use it instead of a system tar utility,
• build cabal-install agaisnt tar-HEAD and employ it.

Long file names and symbolic links are areas of special interest, because they are undergoing massive changes.

[elldritch]

Great, looking forward to it! We are already using HEAD on https://github.com/fossas/tar. Things have been great for us thus far, I'm excited for the new release.

[Bodigrim]

I've uploaded a release candidate: https://hackage.haskell.org/package/tar-0.6.0.0/candidate

I managed to adapt Cabal to work with it. @mpilgrem could you possibly check how it works with Stack?

[Bodigrim]

Released as https://hackage.haskell.org/package/tar-0.6.0.0

[mpilgrem]

@Bodigrim, I was not able to get to this previously, but may I ask: does the change log entry "Prohibit non-ASCII file names instead of silent corruption." mean that programs, like Stack, which UTF8 encode file names in tar achives cannot now use this version of the package? For example, when creating sdist archives, Stack has:

  let tarPath isDir fp =
        case Tar.toTarPath isDir (forceUtf8Enc (pkgIdName FP.</> fp)) of
          Left e -> prettyThrowIO $ ToTarPathException e
          Right tp -> pure tp
      -- convert a String of proper characters to a String of bytes in UTF8
      -- encoding masquerading as characters. This is necessary for tricking the
      -- tar package into proper character encoding.
      forceUtf8Enc = S8.unpack . T.encodeUtf8 . T.pack

[Bodigrim]

Unfortunately this is unlikely to work, yes.

I do not recommend playing fast and loose with filenames, but I don't have fundamental reservations against providing ByteString -> TarPath function, which would allow you to trick tar.

There likely to be bigger compatibility issues though.

[mpilgrem]

Thanks. Other parts of Stack use the tar-conduit package, which does handle UTF8 encoding. I had some involvement with that package in fixing a problem with long file paths, and during that came across the pax extension to the old ustar: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html. UTF8 encoding is part of the pax standard (see the section 'pax Archive Character Set Encoding/Decoding').

[hasufell]

@mpilgrem we're planning to do a major release after migrating to OsPath: #88

On unix, this will be encoding agnostic (so anything goes) and on windows it will assume UTF-8 when decoding from the tar archive.

[hasufell]

@Bodigrim maybe a discourse post would help get more attention and users testing it.

My hope is that we get this library into a state beyond "cabal uses it", which has been annoying me for some time.

I'd switch ghcup back to it, if we had a fix for: #57