cannot build newer cabal-install with Setup.hs

[juhp]

Describe the bug
I am trying to build latest cabal-install for Fedora with ghc-9.8.4.
But since I am packaging for a distro I use Setup.hs not cabal-install for building packages.
However I am not able to get cabal-install to compile against latest Cabal-syntax,
instead it is prefers the Cabal-syntax from ghc and so fails. You can say this is essentially v1-build.

Is there some way I can force Cabal is use the new Cabal-syntax version?

Actual result

src/Distribution/Client/FetchUtils.hs:203:67: error: [GHC-83865]
    • Couldn't match type ‘Distribution.Types.PackageId.PackageIdentifier’
                     with ‘Cabal-syntax-3.10.3.0:Distribution.Types.PackageId.PackageIdentifier’
      Expected: Cabal-syntax-3.10.3.0:Distribution.Types.PackageId.PackageIdentifier
        Actual: PackageId
      NB: ‘Cabal-syntax-3.10.3.0:Distribution.Types.PackageId.PackageIdentifier’
            is defined in ‘Distribution.Types.PackageId’
                in package ‘Cabal-syntax-3.10.3.0’
          ‘Distribution.Types.PackageId.PackageIdentifier’
            is defined in ‘Distribution.Types.PackageId’
                in package ‘Cabal-syntax-3.12.1.0’
    • In the second argument of ‘Sec.indexLookupFileInfo’, namely
        ‘pkgid’
      In a stmt of a 'do' block:
        fileInfo <- Sec.indexLookupFileInfo callbacks pkgid
      In the first argument of ‘Sec.catchChecked’, namely
        ‘(do fileInfo <- Sec.indexLookupFileInfo callbacks pkgid
             sz <- Sec.FileLength . fromInteger <$> getFileSize file
             if sz /= Sec.fileInfoLength (Sec.trusted fileInfo) then
                 warnAndFail "file length mismatch"
             else
                 do res <- Sec.compareTrustedFileInfo (Sec.trusted fileInfo)
                             <$> Sec.computeFileInfo (Sec.Path file :: Sec.Path Sec.Absolute)
                    if res then pure True else warnAndFail "file hash mismatch")’
    |
203 |                     fileInfo <- Sec.indexLookupFileInfo callbacks pkgid
    |                                                                   ^^^^^

src/Distribution/Client/FetchUtils.hs:289:36: error: [GHC-83865]
    • Couldn't match type ‘Distribution.Types.PackageId.PackageIdentifier’
                     with ‘Cabal-syntax-3.10.3.0:Distribution.Types.PackageId.PackageIdentifier’
      Expected: Cabal-syntax-3.10.3.0:Distribution.Types.PackageId.PackageIdentifier
        Actual: PackageId
      NB: ‘Cabal-syntax-3.10.3.0:Distribution.Types.PackageId.PackageIdentifier’
            is defined in ‘Distribution.Types.PackageId’
                in package ‘Cabal-syntax-3.10.3.0’
          ‘Distribution.Types.PackageId.PackageIdentifier’
            is defined in ‘Distribution.Types.PackageId’
                in package ‘Cabal-syntax-3.12.1.0’
    • In the second argument of ‘Sec.downloadPackage'’, namely ‘pkgid’
      In a stmt of a 'do' block: Sec.downloadPackage' rep pkgid path
      In the second argument of ‘($)’, namely
        ‘do info verbosity ("Writing " ++ path)
            Sec.downloadPackage' rep pkgid path’
    |
289 |           Sec.downloadPackage' rep pkgid path
    |                                    ^^^^^

Expected behavior
Build using the Cabal-syntax I had prepared and built for it first.

System information

• Operating system: Fedora Linux Rawhide
• ghc 9.8.4

Additional context
Since "forever" Fedora (or other distros) have just packaged and shipped the cabal-install that corresponds to the version of Cabal in their ghc version, but now I am trying to see if I can also have a package for the latest cabal-install built with bundled Cabal and Cabal-syntax (and cabal-install-solver).

[juhp]

Hmm well Setup.hs is pretty fragile I realise - one could almost say bounds are ignored perhaps if using an inplace user db.
Someone can correct my statement perhaps. At least it can't handle multiple library versions well I think.

I guess I may have to adopt --off-line to improve the situation - this will be fun

[ulysses4ever]

Hey @juhp! I don't have much to add but just wanted to confirm that you're not alone in wanting more clarity around dependency handling in Cabal-the-library / Setup.hs interface. It has been mentioned in the past that Cabal-the-library has its own "simple solver", e.g. see this comment from @grayjay. I don't know that this "simple" solver is documented anywhere.

[sebright]

Yes, here is the simple solver:

cabal/Cabal-syntax/src/Distribution/PackageDescription/Configuration.hs

Line 183 in 04ab16c

resolveWithFlags

It looks like it should respect version bounds, but I don't know when it is used.

[juhp]

Yes normally Setup does respect bounds - the problem occurs for me when I use ./Setup register --inplace as a hack when building library deps bundled in a distro package. (Fedora discourages bundling, but sometimes I have to due to lack of package review manpower.)

[ulysses4ever]

@juhp is your workflow documented anywhere? It could be insightful to see a reproducer.

Also, maybe you could chime in on this issue: #10934

Generally, we're getting inquiries about using cabal-install-sans-the-solver regularly. It'd be good to have a central place to discuss this use case. Not sure what that should be.

[juhp]

Sorry was busy with "other stuff"...

My "workflow"? hmm let me see: basically like this
https://src.fedoraproject.org/rpms/ghc-rpm-macros/blob/rawhide/f/macros.ghc-extra#_93
It might be hard to read with all in RPM macros.

ie While building I create a dummy HOME dir and "v1 install" user packages there (with Setup register --inplace).
This lets me build a stack of dependencies.
This hack has worked for me well for many years (it is used to build plenty of Fedora packages including pandoc and stack).

But as noted in this issue it seems to breakdown when it comes to replacing existing global Haskell installed libs (or at least core libs like Cabal).

[geekosaur]

That sounds like the usual problem that bootlibs are preferred by the solver (because they must be used if ghc-lib is used, but there's no way to wire that constraint into the solver). You can use --constraint to override it, but I don't know how hard that would be in an RPM macro. There is otherwise no good way to do it.