[Hackage] #558: Spec needs updating for hc-pkg

Hackage trac at galois.com
Sun May 31 18:42:12 EDT 2009

#558: Spec needs updating for hc-pkg
  Reporter:  duncan         |        Owner:         
      Type:  defect         |       Status:  new    
  Priority:  normal         |    Milestone:         
 Component:  Cabal library  |      Version:
  Severity:  normal         |     Keywords:         
Difficulty:  unknown        |   Ghcversion:         
  Platform:                 |  
 Section 3.3 describes the hc-pkg tool:


 It leaves these questions unanswered:
   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:
   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

 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

More information about the cabal-devel mailing list