#15478: ghc-pkg package config validation too strict -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Registration of a package using the following config works: {{{ name: frob version: 0.1.0.0 id: frob-0.1.0.0-inplace key: frob-0.1.0.0-inplace exposed: True exposed-modules: Baz from base-4.11.1.0:Data.Bool, Foo from base-4.11.1.0:Data.List, Frob depends: base-4.11.1.0 }}} But while GHC is happy to work with the following variant of the above configuration added by hand to the package database, it's not possible to add it via `ghc-pkg register`, because it's rejected at validation phase: {{{ name: frob version: 0.1.0.0 id: frob-0.1.0.0-inplace key: frob-0.1.0.0-inplace exposed: True exposed-modules: Baz from base:Data.Bool, Foo from base:Data.List, Frob depends: base }}} We get the following error: {{{ $ ghc-pkg register frob.conf frob-0.1.0.0: module reexport refers to a non-existent defining package: base (use --force to override) }}} This is unfortunate, because in general unit-id's don't just have version numbers but also hashes, and in some settings these can be hard to guess. The general point is that ghc-pkg should be exactly as permissive as GHC itself, not less or more. One way to achieve that is to make the `checkModule` function in `utils/ghc-pkg/Main.hs` (called by `validatePackageConfig`) use `lookupPackageName` as a fallback to `lookupUnitId`, and say that if `lookupPackageName` returns exactly one result (i.e. the name is unambiguous) then that should be considered okay. Perhaps not A-okay, because the name could become ambiguous in the future when more entries are added to the database, but that should at most be a warning, not an error, I think. Note: in principle we should be able to use the `--force` flag here to bypass the results of configuration validation. But oddly enough, `--force` ''filters out'' entries that it objects about, rather than just letting them pass through. So `--force` is not a workable workaround. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15478 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler