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

GHC ghc-devs at haskell.org
Mon Aug 22 21:59:26 UTC 2016


#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 ezyang):

 So, what do you want to happen if a single package database has multiple
 exposed copies of a package; e.g. package.conf has both p-0.1 and p-0.2
 (which are both exposed). Then do you want p-0.2? How about if it has two
 copies of p-0.2 (with different installed package IDs)? Which one is
 picked is left unspecified?

 It's also worth mentioning how the `exposed` flag ties into this. For the
 initial visibility calculation, you probably don't want not-exposed
 packages to be considered at all. So if we have pkg-0.1 (exposed), and
 then on the occluding package db, pkg-0.2 (not exposed), we should use
 pkg-0.1. (Maybe you don't care, because you never not expose? But the
 behavior needs to be ironed out.)

 If so, what should happen if I say `-package pkg`? The current behavior
 (without occlusion) is to pick the latest version in ANY database, no
 matter if it's exposed or not. So I guess we would then have to pick out
 pkg-0.2 from the top database, hiding pkg-0.1 in the process.

 I am also unsure about this comment:

 > If the package is broken it should report error rather than silently
 choosing from the next db.

 OK I also need more clarification on this. So if I say `-package base` you
 still want to pick out `base` from the system package database, right? So
 do you want something like, "if you request a package `pkgname`, and it is
 occluded by a broken package, you want this to error. Do you also want
 this behavior for `-package pkg-1.0`? What if there are two copies of
 `pkg-1.0` in the top-most package db, one is broken and one isn't? How
 about if there is `pkg-0.9` which is broken and `pkg-1.0` which is not?

 Also, suppose there is no `-package` flag specified. If there are broken
 packages in the top-most database, should we immediately error? (I guess
 not?)

 (When you answer these, please edit the ticket description so that it's
 up-to-date.)

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


More information about the ghc-tickets mailing list