Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#2201 closed bug (fixed)

"ghc-pkg --user describe '*'" fails with empty user db

Reported by: duncan Owned by:
Priority: low Milestone: 6.10.1
Component: Compiler Version: 6.9
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


With ghc 6.9 and later Cabal uses the new "ghc-pkg describe '*'" interface to get info out of ghc-pkg about all the installed packages. It makes one call for each package db, for --global and --user (and any other dbs the user specifies). The --user flag now means to list only the packages from the user db and not the ones from the global one too. It's quite possible that the user package db is empty (or equivalently that the file does not exist yet).

So what goes wrong is that the new search feature treats an empty search result as a failure. That's obviously a useful thing for some queries but is extremely unhelpful for what Cabal wants. It means Cabal fails to configure anything when the user package db is empty because it does not expect ghc-pkg to fail. This blocks the current Cabal HEAD from working with ghc HEAD.

I'd like to put in another request for the ghc-pkg dump feature that I suggested originally. It would just dump all the packages in the describe format. The difference is that it is not a query so we do not fail if the result set is empty. Also, dump should not produce helpful human readable error output like "ghc-pkg: cannot find package matching *" because that will upset Cabal's parser.

Change History (7)

comment:1 Changed 9 years ago by igloo

difficulty: Unknown
Milestone: 6.10 branch

comment:2 Changed 9 years ago by igloo

Priority: normallow

After speaking with Duncan it's not yet clear exactly what it is that Cabal really wants from us.

comment:3 Changed 9 years ago by duncan

Though I should note that we need to have this fixed in the 6.10 release or Cabal will not play nicely with it. The workaround is quite horrible.

So the question is, how should we get the info from ghc-pkg, bearing in mind that in future we expect the package databases to be really quite large, in the 100's of packages.

In some ways the current system cabal-install uses for the hackage package index is quite nice. It loads the entire index into memory but it does not parse each entry immediately. Instead it does that lazily so that if we only inspect a small number of the packages then it's quite cheap.

I think we could do a similar trick with ghc-pkg. If it can dump all the info to stdout sufficiently quickly (even for large databases) then so long as we can identify each record without parsing the whole thing then we can probably make it quick enough.

Splitting just based on seeing "\nname:" is probably quick enough and is probably unambiguous. Or we could consider using some other way to delineate records.

So on balance I think ghc-pkg dump is a sensible way to go, though I'd prefer a better way of identifying record boundaries.

comment:4 Changed 9 years ago by igloo

Milestone: 6.10 branch6.10.1

comment:5 Changed 9 years ago by simonmar

Resolution: fixed
Status: newclosed

ghc-pkg dump implemented:

Fri Jul 11 13:17:39 BST 2008  Simon Marlow <>
  * add "ghc-pkg dump" (fixes #2201)

comment:6 Changed 9 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:7 Changed 9 years ago by simonmar

Operating System: UnknownUnknown/Multiple
Note: See TracTickets for help on using tickets.