Repository navigation
Edited: network-3.1.2.3 doesn't compile on Windows with cabal 3.4.0 #513
Description
Activity
correction:
3.1.2.3works on cabal-3.6.0.0, 3.6 branch and master, but not oncabal-3.4.0.0. So this is a regression.Phew. But we are almost ready to handle this regression, namely 3.6.2 is about to be released.
I don't think it's acceptable to leave
3.4.0.0broken. It's still the recommended version in ghcup, because 3.6.0.0 broke network package and I'll leave it as recommended for a while, until I'm confident 3.6.0.0+ doesn't break again.Reacted by Javier NeiraFair enough. Regardless, we'll try to publish cabal 3.6.2 RSN so that you can start building the confidence, in particular seeing how cabal 3.6.2 handles network 3.1.2.3, even as network 3.1.2.4 is brought back to compatibility with cabal 3.4 (if that's what the network maintainers decide).
- changed the title
[-]network-3.1.2.3 doesn't compile on Windows with cabal 3.6.2-rc1 (current branch 3.6.) containing a dedicated fix for autoconf problems[/-][+]network-3.1.2.3 doesn't compile on Windows with cabal 3.4.0[/+]on Oct 7, 2021 - changed the title
[-]network-3.1.2.3 doesn't compile on Windows with cabal 3.4.0[/-][+]Edited: network-3.1.2.3 doesn't compile on Windows with cabal 3.4.0[/+]on Oct 7, 2021 I don't think it's acceptable to leave
3.4.0.0broken. It's still the recommended version in ghcup, because 3.6.0.0 broke network package and I'll leave it as recommended for a while, until I'm confident 3.6.0.0+ doesn't break again.Sure, but while this stance looks and sounds reasonable on the surface, it's far from practical. cabal 3.4 will simply not work with any
configurefile generated on autoconf >= 2.70. While you are focusing on network here, any package, including public and private ones will not work with cabal 3.4.For
network@kazu-yamamoto can fix it by making the release on a system withautoconf <= 2.69. But again, this only fixes network and you're still left with the other broken packages in the ecosystem.@Mistuke something like that needs to be announced, so people have a migration plan.
Yes agreed, but the breaking change was caused by autoconf not network. Again, you're focusing on network, but this isn't a network problem.
As I said, we can temporarily "fix" network, but how do you suppose we fix every other package people may be using with configure based scripts? If you're taking the principled stance that you want no regressions for users, you need to address the underlying problem, not the single package we control.
Again, you're focusing on network, but this isn't a network problem.
Yes, the immediate problem right now is failing CIs in the wild, not other packages.
My hypothesis is:
- we can make M1 work with configure generated by autoconf-2.69
- then we can mark network-3.1.2.3 release as broken on hackage
- then we can do a point-release fixing the configure script
- then we can make an announcement and explain upgrade-path to the community
- optional: make a cabal-3.4.1.0 release containing the backported fix
Unfortunately, I'm unable to test point 1 right now, because nix on gitlab CI is broken (as always), see #510 (comment)
Edit: configure script generated with autoconf-2.69 confirmed to be working on M1
- added a commit that references this issue
on Oct 7, 2021 O
Please see haskell/cabal#7707