Broken packages not detected by `ghc-pkg check` using Setup.hs (Gentoo Linux)

[hololeap]

Describe the bug

There is a recurring but difficult to reproduce bug that has been causing issues for Gentoo users who are installing Haskell packages through the system package manager. Normally, when a dependency is updated, a program called haskell-updater is run to collect all broken packages so that they may be recompiled (using ghc-pkg check to enumerate the broken packages). Occasionally some packages are not reported as broken which leads to an error such as:

./setup build
Preprocessing library 'pandoc-crossref-internal' for pandoc-crossref-0.3.16.0..
Building library 'pandoc-crossref-internal' for pandoc-crossref-0.3.16.0..
<command line>: cannot satisfy -package-id pandoc-3.1.7-46M3R0SzpHl1gE0anXTx8l
    (use -v for more information)

The error message says that a certain package-id cannot be satisfied, however it is easy to verify that it is indeed installed on the system. This seems to cause ghc-pkg check to think that the package is not broken. So far, this has only affected reverse-dependencies of pandoc, so the workaround has been to tell users to recompile pandoc then try recompiling the package that threw the error. So far, this workaround has been successful 100% of the time.

To Reproduce

The behavior is difficult to reproduce, but it seems to happen fairly regularly to Gentoo users who are rebuilding reverse-dependencies of pandoc due to ABI breakages. It has been reported a handful of times for pandoc-lua-engine, pandoc-crossref, and pandoc-cli.

Expected behavior

ghc-pkg check should be reporting the broken package (pandoc in all cases so far) so that haskell-updater can mark it as needing a recompile, which is performed by Gentoo's package manager.

System information

There may be other setups that have run into this bug, but the only ones that gave proper documentation were running:

• Gentoo Linux, haskell-updater 1.3.3, portage package manager 3.0
• cabal-3.6.3.0, ghc-9.2.8

Additional context

There are much more details and discussion here:

https://github.com/gentoo-haskell/gentoo-haskell/issues/1469

Specifically, this comment may be of special interest as it includes scan data on a read-only btrfs snapshot that was taken immediately after the bug was hit (I still have the snapshot if it is needed):

https://github.com/gentoo-haskell/gentoo-haskell/issues/1469#issuecomment-1986663730