registerPackage fails with multiple command line --package-conf= flags

[r6]

in registerPackage the database to operate on is filtered, whereas the databases to validate are *truncated*. The trucation can be seen in the code:

let truncated_stack = dropWhile ((/= to_modify).location) db_stack -- truncate the stack for validation, because we don't allow -- packages lower in the stack to refer to those higher up. validatePackageConfig pkg truncated_stack auto_ghci_libs update force

notice the use of dropWhile instead of filter. The problem is that if I want to update a package with a command with multiple --package-conf= parameters, then these parameters get ignored during validation and if the package being installed depends on the packages in these databases, the installation will fail (unless --force is used). For example if you run the command

ghc-pkg --package-conf=myPkg1 --package-conf=myPkg2 --package-conf=myPkg3 --global --user update newPkg.conf

then the command will fail with the error ""something" doesn't exist (use --force to override)" if newPkg.conf depends on something in on of myPkgs.

In fact, with the above command, the truncated_stack consists of only two packages: [the-user-pkg,the-global-pkg].

I think the fix is to use a filter instead of dropWhile, but maybe there is some purpose behind using dropWhile. In any case a bug does exist because the above ghc-pkg command should succeed.

[simonmar]

This is the documented behaviour of ghc-pkg. In the output of ghc-pkg --help:

  When asked to modify a database (register, unregister, update,
  hide, expose, and also check), ghc-pkg modifies the global database by
  default.  Specifying --user causes it to act on the user database,
  or --package-conf can be used to act on another database
  entirely. When multiple of these options are given, the rightmost
  one is used as the database to act upon.

So in your command line:

ghc-pkg --package-conf=myPkg1 --package-conf=myPkg2 --package-conf=myPkg3 --global --user update newPkg.conf

Since --user is the rightmost option, that is the DB to act on. The user DB can only depend on the global DB, so you get the stack [user,global].

[r6]

Where is it documented that user databases cannot depend on package-conf databases?

Also, what is the motivation for such a restriction?

[simonmar]

Replying to r6:

Where is it documented that user databases cannot depend on package-conf databases? Also, what is the motivation for such a restriction?

Nowadays the ordering of package databases is less important than it used to be, because we have Package Ids, so shadowing is harmless and a missing package database just causes an error. So we could treat them like a set instead of a stack.

However, I think it's useful to prevent the user pacakge database from depending on other external package databases - it's a reasonable sanity check, and prevents you from installing packages in the user database that are broken without the appropriate -package-conf flag.