[GHC] #15391: Maybe ghc-pkg register should unregister packages with "incompatible" signatures

[GHC]

#15391: Maybe ghc-pkg register should unregister packages with "incompatible"
signatures
-------------------------------------+-------------------------------------
           Reporter:  ezyang         |             Owner:  (none)
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:  8.6.1
          Component:  ghc-pkg        |           Version:  8.4.3
           Keywords:  backpack       |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 Consider the following situation:

 1. I register package 'p-0.1-inplace' instantiated with 'P =
 base:Data.Map'
 2. I register package 'p-0.1-inplace' instantiated with 'P =
 base:Control.Monad'

 Even though the IPID of these two packages is the same, we clearly want to
 keep both of them in the database. This thus motivates the following lines
 in ghc-pkg

 {{{
      removes = [ RemovePackage p
                | not multi_instance,
                  p <- packages db_to_operate_on,
                  mungedId p == mungedId pkg,
                  -- Only remove things that were instantiated the same
 way!
                  instantiatedWith p == instantiatedWith pkg ]
 }}}

 OK... now consider the following situation

 1. I register package 'p-0.1-inplace' instantiated with 'P =
 base:Data.Map'
 2. I register package 'p-0.1-inplace', instantiated with nothing (I have
 edited 'p' such that it has no more signatures)

 So... ghc-pkg is going to keep both of these packages (per the logic
 above). But is that really what we want? Now the package database is in a
 half-consistent state, where the instances of 'p-0.1-inplace' are not
 consistent with the number of holes they are supposed to have. So let us
 suggest an invariant:

 INVARIANT: All packages which have the same IPID in a package database are
 self-consistent with each other.

 OK, so given this invariant, what do we have to do in step 2? It would
 seem that when we get a prospective package to register, we must *find all
 packages which are incompatible with it*, and remove them from the package
 database. So, given a package with a set of holes H, we must remove all
 packages with holes H' such that H = H'

 I'm not completely convinced this is a good idea. Usually ghc-pkg only
 removes a single package in response to a new registration, and this
 behavior could result in lots of packages getting unregistered, more than
 you might expect. On the other hand, if you think of the package database
 in a more hierarchical manner, it makes sense that changing the root
 registration would invalidate all the children.

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