Ticket #558 (new enhancement)
Spec needs updating for hc-pkg
| Reported by: | duncan | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Cabal specification | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Difficulty: | hard (< 1 day) | |
| GHC Version: | Platform: |
Description
Section 3.3 describes the hc-pkg tool:
http://haskell.org/cabal/proposal/x272.html#AEN351
It leaves these questions unanswered:
Note: Can we give the --user flag to hide, expose, describe? Can we register a package that is already registered? What if it's registered as a global package and we register it as a user package?
It makes this suggestion which has never been implemented:
Note: Some of these commands (unregister, hide, and describe) make sense for package IDs which offer a range, such as "hc-pkg unregister hunit<2.3".
Also, we should standardise hc-pkg dump and the format it produces. It's the only sensible way for tools to get that info. Otherwise they must call hc-pkg describe 100's of times which is unreasonably slow.
There is no method to construct a new package database. There is nothing specified to allow for specific package databases.
Should we standardise ghc-pkg's --force or --force-files? It may also be useful to allow a package to be registered or checked against a virtual root, eg when the files are not yet installed.
There is no specification on the meaning of stacks of package databases, ie how do we interpret package collections when we merge several. Current semantics is a bit odd when user packages shadow global packages.
Partly this is standardising existing practice and partly it's asking for extensions.
If we accept the relative paths extension that that must be documented too along with a way to find the global and user package dbs.
