Skip to content

cabal-install 3.16: allow tar-0.7 #11225

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: 3.16
Choose a base branch
from
Open

cabal-install 3.16: allow tar-0.7 #11225

wants to merge 1 commit into from

Conversation

juhp
Copy link
Collaborator

@juhp juhp commented Sep 23, 2025

@juhp juhp changed the title cabal-install.cabal: allow tar-0.7 cabal-install 3.16: allow tar-0.7 Sep 23, 2025
@juhp juhp mentioned this pull request Sep 23, 2025
Open
@Mikolaj
Copy link
Member

Mikolaj commented Sep 23, 2025

Why not backport #11209 instead?

@geekosaur
Copy link
Collaborator

IIRC these are actually just a requirement of Fedora; there's no actual backporting or etc. requirement, just a metadata update, as with the earlier ticket for 3.12. (Well, for 3.16 we probably do want to backport if needed. That said, I thought we'd fixed this before the branch.)

@juhp
Copy link
Collaborator Author

juhp commented Sep 23, 2025 •
edited
Loading

No it is for future stackage as is the other one too: hence the stackage ticket.
Will be needed when Stackage nightly moves to ghc-9.14.

Would be great if cabal kept up with upstreams more proactively.

@juhp
Copy link
Collaborator Author

juhp commented Sep 24, 2025

Why not backport #11209 instead?

I would like both: 3.14 should not be ahead of 3.16

@Mikolaj
Copy link
Member

Mikolaj commented Sep 24, 2025

Why not backport #11209 instead?

I would like both: 3.14 should not be ahead of 3.16

Yes, I mean, why not backport #11209 twice instead? In particular, it has some more code changes, which is probably required (tar has changed its API). But, in general, it's better to backport things.

@geekosaur
Copy link
Collaborator

It's not strictly required, but the new API fixes a bug where you can run out of file descriptors.

@juhp
Copy link
Collaborator Author

juhp commented Sep 24, 2025 •
edited
Loading

Ah I see sorry (would help if I actually opened the link my bad) - I wrongly assumed you were talking about my other PR.

Sure we can if it is easy - my concern is only to lift the tar bound: let me try to rebase then later

@geekosaur @juhp
support tar-0.7.0.0
8bfecbc 
Use the new functionality (which didn't make the changelog) when
available; see #11131. This moves `createTarGzFile` to
`Distribution.Client.Compat.Tar` with a re-export.
@juhp
Copy link
Collaborator Author

juhp commented Sep 28, 2025

Okay I cherry-picked @geekosaur's PR commit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@juhp @Mikolaj @geekosaur