#558: Spec needs updating for hc-pkg ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- 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. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/558 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects