[GHC] #10622: Rename Backpack packages to units

[GHC]

#10622: Rename Backpack packages to units
-------------------------------------+-------------------------------------
        Reporter:  ezyang            |                   Owner:  ezyang
            Type:  task              |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Compiler          |                 Version:  7.11
      Resolution:                    |                Keywords:  backpack
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:  Phab:D1057
-------------------------------------+-------------------------------------

Comment (by ezyang):

 And here is a counter-counter-proposal, where simply REDUCE sharing:

 1. The basic idea is to defer making libraries/bundles of hi files until
 we have a complete, definite package that has been Cabalized. So if we
 have something like:
 {{{
 package p where
   signature H
   module P
 package q where
   module H
   include p
 }}}
    distributed with a `q.cabal`, `p` NEVER SHOWS UP in the installed
 package database; not even the version of it instantiated with `q`.

 2. This obviously breaks type-checking, since when we build `p` will still
 be compiled to a specific package key `p(Q -> q:H)`, but this package key
 won't be anywhere in our installed package database. So libraries like `q`
 will get a new type of entry in the installed package database: they are
 **fat installed packages** which can contain files for more than one
 package key. These keys are enumerated in the entry installed package
 database, and you just look in `import-dirs/key` to find the relevant
 interface files. So `p`'s interface files will live in something like `q
 -install-dir/p_KEY`. Cabal also records the ABI hash of each of the sub-
 packages in a fat package.

 3. Suppose `p` is an indefinite package with a `p.cabal` of its own.
 Neither the generic `p` nor the instantiated versions of `p` have direct
 entries in the package database: you will only file `hi` files/libraries
 under the fat installs of other definite packages with used `p`.

 4. What happens in this situation, when `q1` and `q2` are built in
 parallel? (Suppose each package has its own Cabal file)
 {{{
 package p where
   signature H
   module P
 package h where
   module H
 package q1 where
   include h
   include p
   module Q1
 package q2 where
   include h
   include p
   module Q2
 }}}
    `h` is a normal package and can get installed as usual. `q1` and `q2`
 are FAT installed packages, they get installed with hi files and libraries
 for `p(H -> h:H)`. In particular, this means that means that `p`
 instantiated with `h` is DUPLICATED in these two fat installed packages.
 To avoid disaster from incompatible duplicate packages, we verify that for
 every duplicated package key in the package database, the ABI hashes are
 the same. This will work great if we have deterministic builds, and not so
 great if they are nondeterministic.

 5. Let's say we instantiate a package, and we discover that a fat package
 which we don't directly depend on instantiated it already. What do we do?
 It should be OK to reuse it, but when Cabal goes and installs, it must
 copy the interface files and libraries from the other fat package into our
 new fat package.

 6. This makes the story great for distribution packagers: they don't have
 to worry about two (morally separate) packages depending on common
 files/libraries which need to be installed in the same location. This
 would require a subpackage, but Debian is unlikely to want to create lots
 and lots of little packages to get the sharing we're aiming for here.

 I actually kind of suspect this is what Simon wanted to do from the
 beginning; apologies for not figuring it out sooner.

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