Depend on tar-0.6.3.0

[mpickering]

tar-0.6.3.0 has much improved performance of deserialising .tar index
which has significant ramifications for the start-up time of
cabal-install.

See #10110

[ffaf1]

I wonder if this compat module can be axed then.

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

Lines 4 to 18 in e1f73a4

	{- FOURMOLU_DISABLE -}
	module Distribution.Client.Compat.Tar
	( extractTarGzFile
	#if MIN_VERSION_tar(0,6,0)
	, Tar.Entry
	, Tar.Entries
	, Tar.GenEntries (..)
	, Tar.GenEntryContent (..)
	, Tar.entryContent
	#else
	, Tar.Entries (..)
	, Tar.Entry (..)
	, Tar.EntryContent (..)
	#endif
	) where

I also wonder: are we introducing some indirect constraint on base?

[ulysses4ever]

It's great to hear about tar advancements. Reacting to these with bumping the lower bound seems too harsh to me.

[mpickering]

@ffaf1 A good question, tar builds with base >= 4.11 which goes back to 8.4.4 at least.

@ulysses4ever It's up to the maintainers what they wish to do, but older versions of tar have a non-performant implementation of deserialise so if you build cabal-install against them then you will suffer slower start-up times.

I will at least bump the index state for release and bootstrap jobs (which will then pick tar-0.6.3)

[ulysses4ever]

older versions of tar have a non-performant implementation of deserialise so if you build cabal-install against them then you will suffer slower start-up times.

I understand. I don't see why you want to disallow that. If your plan allows a newer version of tar, the solver will pick it up anyway. But otherwise, with this change, you just get stuck.

Updating the index state makes sense, thank you.

[mpickering]

I suppose I see it in the same way as if a previous version of the package had a serious bug, you wouldn't want to allow your users to build against that package. I'll remove the tight lower bound once CI passes.

[mpickering]

I have removed the more aggressive lower bound on cabal-install now (which doesn't seem like the best thing to do in my opinion).

So can someone please approve the remaining changes which bumps the index state and regenerates the bootstrap plans to include tar-0.6.3.0.

[Mikolaj]

LGTM

[Mikolaj]

If nobody objects, let's expedite this PR and the backport.

[ffaf1]

What about the Compat module @mpickering? Is it still needed?

[Mikolaj]

@ffaf1: we haven't bumped tar beyond (0,6,0), after all, so it seems it is needed? I guess we could have made such a modest bump, but we are in a hurry this time.

I haven't heard objections, so I'm force-merging.

[Mikolaj]

@mergify backport 3.12

[mergify]

backport 3.12

✅ Backports have been created

• #10123 Depend on tar-0.6.3.0 (backport #10120) has been created for branch 3.12 but encountered conflicts

[Mikolaj]

Merged. @mpickering: thank you again.

And we have conflicts in the backport. :(