[GHC] #9265: Extend PackageId to include version dependency information

[GHC]

#9265: Extend PackageId to include version dependency information
-------------------------------------+------------------------------------
        Reporter:  ezyang            |            Owner:  ezyang
            Type:  feature request   |           Status:  new
        Priority:  normal            |        Milestone:
       Component:  Package system    |          Version:  7.9
      Resolution:                    |         Keywords:  backpack
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------
Description changed by ezyang:

Old description:

> [MultiInstances Multiple installed instances of a package] has been a
> long sought after feature to alleviate Cabal hell, and was the subject of
> an [GSoCMultipleInstances GSoC project] that ultimately never got merged
> into HEAD.
>
> This ticket is our latest attack on the problem, summarized as: add a
> version dependency hash to the `PackageId` (NOT the `InstalledPackageId`)
> associated with packages in the database.  This approach is distinguished
> from the prior attempts as follows:
>
> - We make no attempt to support multiple installations of different ways
> or ABI-compatible versions of a library (e.g. with/without
> optimizations.) This corresponds to supporting multiple
> InstalledPackageIds in a database; in our case, we're supporting multiple
> `PackageId`.
>
> - We do not have to deal with conflicting "instances" in GHC's package
> resolver: multiple instances can be simultaneously loaded and used in a
> single compiled program. This is because PackageIds are baked into the
> exported linker symbols, so different versions will have different names
> and can peacefully coexist.
>
> - We do not have to deal with the delicate ordering problem of
> calculating an ABI hash when configuring a package, which is prior to
> when we actually know it (ABI hash is only known after compilation),
> because our hash is based ONLY on dependency resolution choice.
>
> - In absence of preference for previously installed packages, our Cabal
> dependency resolution stays exactly the same: Cabal picks versions, and
> from these choices we calculate the dependency hashes. With preference,
> we will have to do a little more work.
>
> - We do not attempt to garbage collect old packages. Because we are not
> dependent on ABI, there is not an explosion of installed pacakges from
> package development; new installed packages only occur when version
> numbers are bumped up, or packages are installed in a combinatorially
> different fashion.

New description:

 [wiki:Commentary/Packages/MultiInstances Multiple installed instances of a
 package] has been a long sought after feature to alleviate Cabal hell, and
 was the subject of an [wiki:Commentary/GSoCMultipleInstances GSoC project]
 that ultimately never got merged into HEAD.

 This ticket is our latest attack on the problem, summarized as: add a
 version dependency hash to the `PackageId` (NOT the `InstalledPackageId`)
 associated with packages in the database.  This approach is distinguished
 from the prior attempts as follows:

 - We make no attempt to support multiple installations of different ways
 or ABI-compatible versions of a library (e.g. with/without optimizations.)
 This corresponds to supporting multiple InstalledPackageIds in a database;
 in our case, we're supporting multiple `PackageId`.

 - We do not have to deal with conflicting "instances" in GHC's package
 resolver: multiple instances can be simultaneously loaded and used in a
 single compiled program. This is because PackageIds are baked into the
 exported linker symbols, so different versions will have different names
 and can peacefully coexist.

 - We do not have to deal with the delicate ordering problem of calculating
 an ABI hash when configuring a package, which is prior to when we actually
 know it (ABI hash is only known after compilation), because our hash is
 based ONLY on dependency resolution choice.

 - In absence of preference for previously installed packages, our Cabal
 dependency resolution stays exactly the same: Cabal picks versions, and
 from these choices we calculate the dependency hashes. With preference, we
 will have to do a little more work.

 - We do not attempt to garbage collect old packages. Because we are not
 dependent on ABI, there is not an explosion of installed pacakges from
 package development; new installed packages only occur when version
 numbers are bumped up, or packages are installed in a combinatorially
 different fashion.

--

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