Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#4884 closed bug (invalid)

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

Reported by: r6 Owned by:
Priority: normal Milestone: 7.4.1
Component: ghc-pkg Version: 6.12.3
Keywords: Cc:
Operating System: Linux Architecture: x86
Type of failure: Incorrect result at runtime Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):


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.

Change History (4)

comment:1 Changed 5 years ago by igloo

  • Milestone set to 7.2.1

comment:2 Changed 5 years ago by simonmar

  • Resolution set to invalid
  • Status changed from new to closed

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

comment:3 follow-up: Changed 5 years ago by r6

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

Also, what is the motivation for such a restriction?

comment:4 in reply to: ↑ 3 Changed 5 years ago by 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.

Note: See TracTickets for help on using tickets.