[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:  patch
        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:D2613
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by duncan):

 I'm struggling to get this. Seems to me that anything based on ABI is
 fishy since ABI is not a reliable indicator of identity. The 'id' field is
 for identity and the proper solution is to make that strong enough to be a
 proper identity.

 I'm sympathetic to @simonmar's point that it's nice to be able to just
 union all dbs. And that should work just fine provided that ids are strong
 enough. If your use case could in principle be handled by coping all the
 package.db/*.conf files from all the DBs into one DB then you're in a
 situation where there is only one instance of any pkgid already, and
 unordered unioning is fine.

 If we're using weak package ids, as in Simon's example in comment:30 then
 we're in deep trouble already. There's no way to know which r instance the
 q package needs.

 So if I understand correctly, @ezyang is proposing a kludge for this
 situation where we additionally record and stash the ABI use it also on
 all edges. But the ABI isn't enough. The proper solution imho is to
 distinguish the two 'r' instances by giving them different ids.

 But it doesn't sound like the situation @niteria has looks like this,
 right? I assume that you've got the ids actually unique, and you're not
 relying on shadowing. Your example would work just fine with unioning
 presumably.

 I don't mind ABI tracking as an additional sanity check (and it tells you
 when you could plausibly deliberately try switching deps without re-
 compiling), but I don't think we should be using it for anything important
 like disambiguating as part of db merging.

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