search

haskell / cabal

Official upstream development repository for Cabal and cabal-install
https://haskell.org/cabal
Other
1.57k stars 676 forks source link

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

Open hololeap opened 1 week ago

hololeap commented 1 week ago

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:

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

ffaf1 commented 1 week ago

Thanks for the report, @hololeap.

Is cabal doing something wrong that prevents ghc-pkg to function normally? I ask because ghc-pkg is part of GHC, which development happens in a different repository.

hololeap commented 1 week ago

@ffaf1 I believe so, but am not 100% sure. You can see in this gist that ./setup configure has no problems finding pandoc-3.1.7-46M3R0SzpHl1gE0anXTx8l, however when ./setup build is run:

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

My impression is that the hash portion of the package-id should have been changed, but was not. In any case, when I brought this up along with the original bug and diffoscope output in the #ghc channel on libera.chat, I was told this was likely a Cabal bug.