Skip to content


Spec needs updating for hc-pkg #551

bos opened this Issue · 1 comment

2 participants

Haskell member

(Imported from Trac #558, reported by @dcoutts on 2009-05-31)

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 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.

Haskell member

Closing as there's been no activity in years.

We're cleaning up the bug tracker to make it useful again and are thus closing bugs that haven't seen any activity in a long time. Please re-open (or file a new bug) if the problem reappears.

@tibbe tibbe closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.