You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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):
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.
@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.
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 (usingghc-pkg check
to enumerate the broken packages). Occasionally some packages are not reported as broken which leads to an error such as: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 causeghc-pkg check
to think that the package is not broken. So far, this has only affected reverse-dependencies ofpandoc
, so the workaround has been to tell users to recompilepandoc
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 forpandoc-lua-engine
,pandoc-crossref
, andpandoc-cli
.Expected behavior
ghc-pkg check
should be reporting the broken package (pandoc
in all cases so far) so thathaskell-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:
gentoo-haskell/gentoo-haskell#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):
gentoo-haskell/gentoo-haskell#1469 (comment)
The text was updated successfully, but these errors were encountered: