support tar-0.7.0.0

[geekosaur]

The changelog says the only significant change is to GenEntries, which we don't appear to use (local build would have gotten a type error).

---

Template B: This PR does not modify behaviour or interface

E.g. the PR only touches documentation or tests, does refactorings, etc.

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Is this a PR that fixes CI? If so, it will need to be backported to older cabal release branches (ask maintainers for directions).

[geekosaur]

You know, this is skipping FreeBSD whereas my fork is trying to run it. Is there a flipped conditional somewhere? /cc: @hasufell

[geekosaur]

Looks like to get CI to do it requires --allow-newer:tar to satisfy dependencies' constraints.

[Bodigrim]

The reason for tar-0.7.0.0 release was to fix #11131, so presumably we want to update

cabal/cabal-install/src/Distribution/Client/Tar.hs

Lines 58 to 59 in 6915c20

	createTarGzFile tar base dir =
	BS.writeFile tar . GZip.compress . Tar.write =<< Tar.pack base [dir]

to BS.writeFile tar . GZip.compress =<< Tar.write' =<< Tar.pack' base [dir] when tar >= 0.7. It's not strictly necessary to do in this PR (one can argue that simply allowing a new tar is already a step forward), but I think it would make sense to combine.

[geekosaur]

I thought I'd remembered something along those lines, so I went looking at the changelog but it didn't tell me anything useful about that (I suppose it's not an API change but a per-consumer choice?).

[Bodigrim]

Yeah, I should have probably highlighted it in the changelog explicitly, sorry for this.

[geekosaur]

Meanwhile our backward compatibility requirements mean hiding this in Distribution.Client.Compat.Tar, then using CI to test with the old version (one of our dependencies seems to be excluding 0.7.0.0) and a triggered run with CONSTRAINTS/ALLOW_NEWER to test the new. Or local testing like I did before pushing this.

[Bodigrim]

one of our dependencies seems to be excluding 0.7.0.0

I think it's hackage-security, should be easy to fix.

[hasufell]

You know, this is skipping FreeBSD whereas my fork is trying to run it. Is there a flipped conditional somewhere? /cc: @hasufell

This PR does not run the release pipeline. It's skipped.

Your fork runs the release pipeline scheduled only and skips FreeBSD: https://github.com/geekosaur/cabal/actions/runs/17522152727

[ulysses4ever]

Thanks!

[geekosaur]

Unlabeling and dismissing review until I have time to work on the updated call convention this afternoon. That's what will really need to be reviewed.

change is incomplete, and the next step is the one that really needs to be reviewed

[geekosaur]

I think it's hackage-security, should be easy to fix.

Well, except that getting a change released so we can use it can incur a delay, and conceivably it will require the same kind of modification.

[geekosaur]

BTW is there some particular reason why Distribution.Client.Compat.Tar has a #if with an empty true branch instead of #if !…?

[geekosaur]

This is what I get for having to get up 2 hours earlier than usual, sigh.

[Bodigrim]

I tested that this patch is compatible with both old and new tar by running

cabal build cabal-install -c 'tar<0.7'

and

cabal build cabal-install -c 'tar>=0.7' --allow-newer='hackage-security:tar'

[geekosaur]

Hrm. Apparently I can't run a triggered workflow on a PR? (after having to dig into the workflow file to see how to specify the allow-newer/constraints correctly; I'm making a note to add that to the maintainers readme in #10503)

[Mikolaj]

Thank you!