Closed hasufell closed 10 months ago
Only pending PR: https://github.com/haskell/unix/pull/306
@Bodigrim @hs-viktor
My idea was to get this into 9.6.4: https://gitlab.haskell.org/ghc/ghc/-/issues/24017
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.
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?
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?
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:
unix-2.8.4.0
with statx
fixes only, to be included with GHC 9.6.4. unix-2.8.5.0
with os-string
flag, to be included with GHC 9.8.2. Sounds largely reasonable, unless 9.8.2 should instead be 9.9-dev, to be released with 9.10.1 when that's ready.
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.
I'll trust your judgement on this. This is outside my area of competence, beyond the scars building cabal-install 3.[0246]. :-(
@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"
)
changelog
haveStatx
statx.stx_mnt_id
detection on buggy glibc, see GHC #24072throwErrnoIfMinus1Retry
for mkstemp