#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

#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: -------------------------------------+------------------------------------ Comment (by ezyang): No, C libraries won't get mangled; they'll be shared (in much the same way if two different Haskell packages ask for the same C library, they'll get the same one linked in.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9265#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9265: Extend PackageId to include version dependency information -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: high | 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: -------------------------------------+------------------------------------ Comment (by rwbarton): What about packages that include "cbits" where the calling convention (or just semantics) of the C function changes from one version to the next? Won't the linker complain or, worse, just pick one? I guess with dynamic linking it might work. Admittedly, it could already happen that two unrelated packages use clashing names for their incompatible "cbits" C functions, but it seems rather more likely to occur between one version of a package and the next. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9265#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9265: Extend PackageId to include version dependency information -------------------------------------+------------------------------------ Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: high | Milestone: 7.10.1 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: -------------------------------------+------------------------------------ Changes (by thoughtpolice): * milestone: => 7.10.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9265#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#9265: Create PackageKey to replace PackageId, including version dependency information -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: high | Version: 7.9 Component: Package | Keywords: backpack system | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/9265#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler