Release 2.8.4.0

[hasufell]

changelog

• add haveStatx
• fix statx.stx_mnt_id detection on buggy glibc, see GHC #24072
• allow building with newer filepath/os-string
• Use throwErrnoIfMinus1Retry for mkstemp

[hasufell]

Only pending PR: #306

@Bodigrim @hs-viktor

[hasufell]

My idea was to get this into 9.6.4: https://gitlab.haskell.org/ghc/ghc/-/issues/24017

[vdukhovni]

Let's not include the os-string flag as a bug-fix release (2.8.4). Instead this should be 2.9.0. With 2.8.x adding only bug fixes and perhaps some small additions.

[hasufell]

Let's not include the os-string flag as a bug-fix release (2.8.4). Instead this should be 2.9.0. With 2.8.x adding only bug fixes and perhaps some small additions.

Why?

[vdukhovni]

Let's not include the os-string flag as a bug-fix release (2.8.4). Instead this should be 2.9.0. With 2.8.x adding only bug fixes and perhaps some small additions.

Why?

I am concerned about under-tested unexpected build issues for various packages. How confident are you that in complex dependency graphs we won't end up with conflicting outcomes?

[Bodigrim]

I think there are two rather orthogonal question.

• One is whether os-string flag requires a major bump. I don't think so: it's not required by PVP, and major bumps are a precious commodity for boot packages. Each of them (be it bytestring, text, or unix) costs the community dozens if not hundreds of hours of chasing absent maintainers and revisions. It's more reasonable to stick to unix-2.8.4.0 here.

• Another concern is whether we want to propose such change for a stable branch of GHC such as 9.6.4. GHC release managers are usually rightfully reluctant to take not-strictly-bugfix updates of boot libraries at this point, because if anything, anything at all goes wrong they might have to make another patch release, costing a great deal of time and effort. I'm saying this from a practical experience of botching a GHC release with a bytestring update recently.

I am reasonably confident in the behaviour of os-string flag, but I also have a history of GHC builds blocked by boot libraries one way or another, often by very obscure reasons. But on the other hand, if no GHC release includes unix with os-string flag, there will be virtually no user testing and we will not gain any further experience with it.

It would be hugely stressful to make a release, which GHC developers won't be happy to backport to GHC 9.6 branch. In such case we'd have to make another one in a hurry and with non-PVP compliant version (or alternatively deprecating the existing one, and releasing another one atop, which is equally annoying).

I'd suggest we do the following:

• Release unix-2.8.4.0 with statx fixes only, to be included with GHC 9.6.4.
• Release unix-2.8.5.0 with os-string flag, to be included with GHC 9.8.2.

[vdukhovni]

Sounds largely reasonable, unless 9.8.2 should instead be 9.9-dev, to be released with 9.10.1 when that's ready.

[Bodigrim]

Delaying os-string flag until 9.10.1 would be way too conservative IMO, we need to gain some experience with it and split os-string / filepath-1.5 sooner than later. I imagine by GHC 9.10 os-string and filepath-1.5 are to be boot packages.

Realistically, since unix is a boot package, Cabal has very little incentive to rebuild it with non-default set of flags, so you are almost guaranteed to be safe. This is not the case for hackage-security and Cabal / Cabal-syntax split.

[vdukhovni]

I'll trust your judgement on this. This is outside my area of competence, beyond the scars building cabal-install 3.[0246]. :-(

[andreabedini]

@Bodigrim

Realistically, since unix is a boot package, Cabal has very little incentive to rebuild it with non-default set of flags, so you are almost guaranteed to be safe.

To be more precise; it won't do it. cabal-install does not know anything about flags when it comes to pre-installed packages. For boot packages this can have some serious consequences: if unix-2.8.5.0 is preinstalled and allowed by the constraints, it will be used disegarding any flags you might have specified for it. We saw this happen a lot when text introduced the flag simdutf.
(The workaround is to use a "source constraint": --constraint "text source")