[GHC] #12485: -package-db flags now need to be sorted by dependency order

[GHC]

#12485: -package-db flags now need to be sorted by dependency order
-------------------------------------+-------------------------------------
        Reporter:  niteria           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.0.3
       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 simonmar):

 *    db1: p (depends on q)
  *    db2: q (depends on r from db3)
  *    db3: r
  *    db4: r (shadows r from db3)

 I presume you mean that db3:r and db4:r have different ABIs, and q was
 built against db3:r.

 We are given these in the order db1, db3, db4, db2.  Now, since q's
 dependency doesn't say which r it requires, we have to pick one, and the
 only sensible strategy is to pick the rightmost (db4:r).  This is the
 wrong r, so we can get segfaults.



 Given that we can get segfaults even trying to do clever shadowing, I'm
 going to suggest that we don't do clever shadowing at all.

   * Just merge databases from left to right.  When there are multiple
 packages with the same key, we get the rightmost one.

 We would accept the small possibility that if someone has somehow managed
 to create two packages with the same key but different ABIs (which is
 difficult with determinism) then GHC can produce a segfaulting binary.
 Too bad.  It's unlikely, and as a user you can fix it by deleting or
 rebuilding packages.  Furthermore it was always possible to screw up like
 this because the ABI hash is not a complete specification of a package -
 there are semantic differences not captured by the ABI hash.

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