Consider making ghc-pkg fill in abi-depends based on depends
In GHC 8.2, we introduced abi-depends
to solve #12485 (closed). Following the same pattern as all ghc-pkg fields, this field is to be fllled by whoever is performing the registration.
I now suspect designing it this way was a mistake. In https://github.com/haskell/cabal/issues/4728 we have a bug where Cabal is writing nonsense data for abi-depends
, ghc-pkg
isn't noticing it, and GHC is rejecting the package (with a "shadow" warning) when it gets to the end. The problem is the Cabal aggressively caches the contents of the package database (ostensibly because it is expensive to query ghc-pkg
); this means that it is easy to get into a situation where its understanding of the ABIs of its dependencies is out-of-date (because it is not re-reading the database in order to get newer information).
The insult to the injury is, in most cases, ghc-pkg already knows what the ABIs are supposed to be: they're whatever the ABIs of the packages pointed at by 'depends' already in the database are. So ghc-pkg could have computed the abi dependency itself, and prevented this stale data situation from ever happening. This sounds quite attractive to me.
What do people think? Here is one possible proposal (but it is just one in the space):
-
ghc-pkg
will be modified to ignore theabi-depends
field (perhaps with a warning), to prevent itself from being poisoned by buggy versions of Cabal which are giving bad ABI information - Instead,
ghc-pkg
generates theabi-depends
field by looking up dependency IDs from the database. If an ID is not found, it omits the dep fromabi-depends
(this is equivalent to suspending ABI checking in GHC, so this won't break anything; it will just make ABI checking less robust) - Possibly, introduce a new "virtual" field, which can be used to override
ghc-pkg
default
Trac metadata
Trac field | Value |
---|---|
Version | 8.2.1 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | high |
Resolution | Unresolved |
Component | ghc-pkg |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |