Should the "unconstrained build" be off by default for head.hackage

[andreasabel]

With head job we get this in cabal.project: allow-newer: *:Cabal, *:Cabal-syntax, *:array, *:base, *:binary, *:bytestring, *:containers, *:deepseq, *:directory, *:exceptions, *:filepath, *:ghc, *:ghc-bignum, *:ghc-boot, *:ghc-boot-th, *:ghc-compact, *:ghc-heap, *:ghc-prim, *:ghci, *:haskeline, *:hpc, *:integer-gmp, *:libiserv, *:mtl, *:parsec, *:pretty, *:process, *:rts, *:stm, *:system-cxx-std-lib, *:template-haskell, *:terminfo, *:text, *:time, *:transformers, *:unix, *:xhtml,

Usually, its effects are moderated by matching installed constraints in cabal.project.local:

constraints: Cabal installed
constraints: Cabal-syntax installed
constraints: array installed
constraints: base installed
constraints: binary installed
constraints: bytestring installed
constraints: containers installed
constraints: deepseq installed
constraints: directory installed
constraints: exceptions installed
constraints: filepath installed
constraints: ghc installed
constraints: ghc-bignum installed
constraints: ghc-boot installed
constraints: ghc-boot-th installed
constraints: ghc-compact installed
constraints: ghc-heap installed
constraints: ghc-prim installed
constraints: ghci installed
constraints: haskeline installed
constraints: hpc installed
constraints: integer-gmp installed
constraints: libiserv installed
constraints: mtl installed
constraints: parsec installed
constraints: pretty installed
constraints: process installed
constraints: rts installed
constraints: stm installed
constraints: system-cxx-std-lib installed
constraints: template-haskell installed
constraints: terminfo installed
constraints: text installed
constraints: time installed
constraints: transformers installed
constraints: unix installed
constraints: xhtml installed

However, in the "unconstrained build", the cabal.project.local is deleted while the cabal.project remains in place. As a consequence, we can get wild build plans, e.g. Cabal-3.2.1.0 paired with Cabal-syntax-3.8.1.0

src/Hackage/Security/TUF/Layout/Repo.hs:9:1: error:
    Ambiguous module name ‘Distribution.Package’:
      it was found in multiple packages:
      Cabal-3.2.1.0 Cabal-syntax-3.8.1.0

Is this working as intended?

There is a setting unconstrained-build: for cabal.haskell-ciwhich I could set to < 9.6 to prevent such false negatives. Should this maybe on by default for the head job?

Having to put this into the cabal.haskell-ci brings the risk that it remains there forgotten while GHC has long progressed beyond 9.6. What I would really want to put there is != head or so. But I would argue that this could be the default.

[phadej]

Is this working as intended?

Yes. Unconstrained build is... unconstrained. If you use allow-newer things may go bananas. Yet, jobs with prerelease GHC are allowed to fail.

[andreasabel]

Steep learning curve...

I think a brutto allow-newer: *:Foo is often not what I want. What I want 99% of the time is an allow-newer: latest:Foo, which only allows newer Foo for each latest version of any package available.
E.g. allow-newer: Cabal:base would not apply to Cabal-3.2.1.0 which has a native base < 4.15 (and thus is likely outdated). Alternatively, an allow-newer which only allows to skip to the next major version (as opposed to skipping arbitrarily many major versions) would also often be more helpful than the brutto version.

[phadej]

Feel free to request that feature on cabal-install issue tracker. I'd be happy to do allow-newer for the latest (non deprecated) release only.

Note: we have to do wildcard allow-newer: *:base as there is no way to know which of all dependencies will need the relaxed upper bounds (technically each if PVP were followed strictly).