[GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends

22 Oct 2017

      #14381: Consider making ghc-pkg fill in abi-depends based on depends
-------------------------------------+-------------------------------------
           Reporter:  ezyang         |             Owner:  (none)
               Type:  bug            |            Status:  new
           Priority:  high           |         Milestone:
          Component:  ghc-pkg        |           Version:  8.2.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 In GHC 8.2, we introduced `abi-depends` to solve #12485. 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 the `abi-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 the `abi-depends` field by looking up
 dependency IDs from the database. If an ID is not found, it omits the dep
 from `abi-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

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14381
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

GHC

tags

participants (1)