Edited: network-3.1.2.3 doesn't compile on Windows with cabal 3.4.0

[Mikolaj]

Please see haskell/cabal#7707

[hasufell]

correction: 3.1.2.3 works on cabal-3.6.0.0, 3.6 branch and master, but not on cabal-3.4.0.0. So this is a regression.

[Mikolaj]

Phew. But we are almost ready to handle this regression, namely 3.6.2 is about to be released.

[hasufell]

I don't think it's acceptable to leave 3.4.0.0 broken. 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.

[Mikolaj]

Fair 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).

[Mistuke]

I don't think it's acceptable to leave 3.4.0.0 broken. 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 configure file 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 with autoconf <= 2.69. But again, this only fixes network and you're still left with the other broken packages in the ecosystem.

[hasufell]

@Mistuke something like that needs to be announced, so people have a migration plan.

[Mistuke]

@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.

[hasufell]

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:

1. we can make M1 work with configure generated by autoconf-2.69
2. then we can mark network-3.1.2.3 release as broken on hackage
3. then we can do a point-release fixing the configure script
4. then we can make an announcement and explain upgrade-path to the community
5. 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

[Bekalex]

O