#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