[GHC] #11025: Per-database shadowing

[GHC]

#11025: Per-database shadowing
-------------------------------------+-------------------------------------
           Reporter:  ezyang         |             Owner:  ezyang
               Type:  bug            |            Status:  new
           Priority:  high           |         Milestone:  8.0.1
          Component:  Package        |           Version:  7.11
  system                             |
           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 `5b0191f74ab05b187f81ea037623338a615b1619`, I eliminated shadowing, on
 the justification that we should never pick the same component ID
 (previously installed package ID) for two distinct packages unless the
 ABIs of the packages were the same, so we could just globally assume that
 component IDs are unique.

 However, I've recently come across some cases where we can't easily
 actually make this be the case. Here are a few of them:

 1. GHC's build system assumes that the ghc package will always be a
 library name of the form HSghc-7.11.a (i.e. that its component ID is
 ghc-7.11). It's a bit nontrivial to change this assumption, because there
 are stage1 shenanigans which are rewriting the version number to one
 without the date. But obviously if you are bootstrapping GHC with itself,
 the component ID of the GHC you are building will conflict with the
 component ID of the host GHC.

 2. A similar situation exist for bootstrapping packages. When compiling
 GHC, we want to pick fairly deterministic component IDs for it in order to
 avoid needless rebuilding. But then if you turn around and use one of
 these builds to bootstrap GHC, if you use the same deterministic scheme
 you will end up with conflicting component IDs.

 3. More generally, if you are building a package which is already in the
 global database (and thus not easily removable), it is sometimes VERY
 CONVENIENT to be able to pick whatever component ID you want, even if it's
 in the global database. (1) and (2) are cases of this.

 So I think what we want to do is bring back shadowing, but have it operate
 on a PER-DATABASE basis. For example, if we have the following databases:

 {{{
 pkg.conf.1
   foo-0.1-XXX
   bar-0.2-YYY (depends on foo-0.1-XXX)
 pkg.conf.2
   foo-0.1-XXX
   baz-0.3-ZZZ (depends on foo-0.1-XXX)
 }}}

 If we stack pkg.conf.2 on top of pkg.conf.1, we invalidate foo-0.1-XXX
 FROM pkg.conf.1 (which simply means any packages from pkg.conf.1 which
 refer to it.)

 It also occurs to me that we should also be recording the ABIs of packages
 we depend on, to ensure consistency. Consider:

 {{{
 pkg.conf.1
   foo-0.1-XXX (abi is AAA)
 pkg.conf.2
   foo-0.1-XXX (abi is BBB)
 pkg.conf.3
   bar-0.1-YYY (depends on foo-0.1-XXX)
 }}}

 Which is the correct database to use `pkg.conf.3` with? We have no way of
 telling today! Sure, `pkg.conf.3` is incomplete, but this is a supported
 mode of operation.

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