
#12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450, Wiki Page: | phab:D2514 -------------------------------------+------------------------------------- Comment (by ezyang): In the old world, it was OK to resolve clashes in the end because we assumed that if two packages had the same IPID, it would be OK to pick one arbitrarily. In other words, we assumed that equal IPIDs implies equal ABIs, making them interconvertible. We always computed the IPID by running `ghc --abi-hash`. Now, we wanted to stop computing IPIDs based on `--abi-hash`. The reason is that cabal-install wants to assign a unique IPID prior to compilation, based on all of the inputs to the compilation (in Nix-style local builds). ABI hashes get in the way because we find them out too late. In an ideal world, we could assume that if two packages have the same IPID, their ABI hashes are the same. But basically any package manager that is not cabal- install with Nix-style local builds can't really give a guarantee like this. So I decided we should just not assume that ABI hashes are the same, even if the IPIDs are the same. Now, the crux of the issue: it is no longer true that if two packages had the same IPID, it would be OK to pick one arbitrarily. That is only true if the ABIs are the same. If the ABIs are not the same, one needs to shadow the other. But how do we know which packages were compiled for package 1, as opposed to package 2? Without package database ordering, we don't know. (Remember with shadowing in GHC 7.8 was just making sure we didn't have conflicting package id derived symbol names; but since dependencies were always recorded as IPID, it was a pretty simple matter to figure out what to remove. Nothing ever got removed if there was an IPID conflict.) As I mentioned earlier, one way we can resolve this is by recording both the IPID and the ABI of the dependencies of each package. Then we can resolve conflicts at the very end. I suppose there are less invasive ideas where we play more fast and loose about how we combine package databases. But does this explain the situation? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12485#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler