Create PackageKey to replace PackageId, including version dependency information
Multipleinstalledinstancesofapackage has been a long sought after feature to alleviate Cabal hell, and was the subject of an 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.