#12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new 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: | -------------------------------------+------------------------------------- Comment (by niteria):
First, niteria, I'm curious why you need top be able to pass the package databases out of order. If I understand correctly, neither Stack nor Cabal use the databases this way.
I don't use Stack or Cabal to build the packages. I can't do that because I'm building packages needed to build `cabal-install`. The way the packages are built is with `Setup.hs` and a separate `package.db` for each package. The scripts I have would need some additional logic to pass the `-package-db` flags in dependency order. Once I get past that obstacle I'm not sure if Buck or Bazel do any dependency sorting on `-package-db` flags. Putting this constraint on every build system sounds suboptimal to me.
Indeed, when I wrote this patch, I assumed the databases would be in the right order because that's how shadowing works: later databases shadow earlier ones.
Second, it's impossible to do ABI sanity checking in the way it is done today if I can't assume things are in the right order. When the db order was assumed to be specified correctly, I could assume all references to
This is an undocumented change in behaviour in the very least. The manual didn't state that they can be in any order, but also didn't put any constraints on order. People trying to integrate this into their build systems will have no idea that this is the requirement. p-0.1-xxx refer to the topmost package with this IPID in the Stack; if the ABIs mismatch then I should remove everyone below me. But if there might be a reference to that particular package in a later package database, this assumption doesn't hold. This sounds like an implementation detail informing the specification. Is there a fundamental reason why the flags have to be ordered?
Assuming that we DO want databases to be specified in any order (do we?!) here's what I think we should do: We NEVER remove packages because something got shadowed. Either the shadower is ABI compatible (in which case we never need to eliminate anything), OR we immediately error (because we have no idea which ones to eliminate.) I don't know if this brings back enough shadowing to fix bootstrapping though; will have to test.
I'm not familiar with package shadowing and also don't know how it fixes bootstrapping. Your patch doesn't explain it either. If you could explain maybe it would move this issue forward. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12485#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler