[GHC] #12518: Allow customizing immutable package dbs by stacking

[GHC]

#12518: Allow customizing immutable package dbs by stacking
-------------------------------------+-------------------------------------
        Reporter:  harendra          |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       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):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by harendra):

 In general, this ticket is mostly about how we combine multiple databases.
 The existing behavior wrt a single database scope seems to be fine. Since
 stack does not install multiple instances with the same package name in
 the same db it does not matter what is picked in that case. In general I
 guess picking the latest version and any IPID should be fine.

 What you described wrt `exposed` makes sense to me. Though it does not
 matter for my use case. Also, the behavior of `-package` as you described
 is exactly what is required.

 The point of erroring out is to make sure we always have a reliable
 behavior. We should control the behavior rather than GHC doing it
 automatically without us even knowing about it. If a broken package comes
 in the way we have to report error. If we say `-package base`  we pick it
 from the topmost db that has it whether it is broken or not. If it is
 broken we say so. Same for `-package pkg-1.0`. Within a given db scope,
 again it does not matter for my use case so we can use the usual rule of
 latest non-broken package.

 In general one can imagine the following package db policy flags to
 control the behavior more flexibly:
 * `--allow-multiple-ipid`: default is to error on detecting ipid conflict
 * `--ignore-broken-pkgs`: default is to error on encountering broken
 packages.
 * `--allow-multiple-versions`: default is to error on detecting multiple
 versions

 Defaults can be changed but keeping strict defaults may be better for
 reliable behavior. These flags in addition to stacking (`--stacked-pkg-
 dbs`) or unioning combining policy will create a fully flexible system.
 All the above flags always apply to a single db scope. When stacking is in
 effect then across dbs stacking rules will apply (i.e. top db prevails)
 and in a single db scope these flags will apply. When unioning is in
 effect all the dbs are combined into one and these flags are applied to
 the combined db. Though I am not sure if it is worth implementing all of
 this.

 This scheme answers some of your questions elegantly because now we do not
 worry about what is the correct default. For example what do we do if a
 top db has a broken package but a lower one has a working one. If
 `--ignore-broken-pkgs` is specified then we will ignore the top and go
 ahead and use the lower one.

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