GHC does not warn when two conflicting packages with same name are given via a dependent package and -package-db

So I'm compiling a Setup.hs of mypackage, directly with ghc and without use of Cabal.

It has a custom build type and imports Distribution.Extra.Doctest from cabal-doctest.

For compiling mypackage's Setup.hs I give a -package-db that contains a custom Cabal package.

But when I compiled doctest, I did not give that custom Cabal package.

I compile with

ghc -package-db=/tmp/nix-build-hsyslog-5.0.1.drv-0/setup-package.conf.d -package Cabal -j4 -threaded --make -o Setup -odir $TMPDIR -hidir $TMPDIR $i -fforce-recomp -keep-tmp-files -v5

The given package db looks like this:

% ls -lah /tmp/nix-build-hsyslog-5.0.1.drv-0/setup-package.conf.d
total 56K
drwxr-xr-x  2 niklas niklas 4.0K Jul 20 03:14 ./
drwxr-xr-x 12 niklas niklas 4.0K Jul 20 03:49 ../
-r--r--r--  1 niklas niklas  11K Jul 20 02:30 Cabal-2.2.0.1-302vnEvwKgd3FEKLIV6HbI.conf
-r--r--r--  1 niklas niklas 2.3K Jul 20 02:30 cabal-doctest-1.0.6-E57gwmEN5fa2uY0bq8bb44.conf
-rw-rw-r--  1 niklas niklas  31K Jul 20 03:14 package.cache
-rw-r--r--  1 niklas niklas    0 Jul 20 02:30 package.cache.lock

Full ghc-pkg dump -f /tmp/nix-build-hsyslog-5.0.1.drv-0/setup-package.conf.d output

This results in the linker flags:

-L/nix/store/hfi080vzqqzfip6bd6x4cxc2jgj56xn3-ghc-8.4.3/lib/ghc-8.4.3/Cabal-2.2.0.1
-L/nix/store/6x9r3kqn8h961ilaw2nj474jrfyg28lp-Cabal-2.2.0.1/ghc-8.4.3/Cabal-2.2.0.1
...
-lHSCabal-2.2.0.1
-lHSCabal-2.2.0.1-302vnEvwKgd3FEKLIV6HbI

When this happens, GHC will always prefer the Cabal version from the global package db, and not the one I have given with -package.

This results in my compiled Setup file to not use the Cabal version I desire.

I would expect GHC to warn me when two Cabal versions are at play, or entirely refuse to compile, instead of picking the one that I have NOT explicitly specified.

See full -v5 ghc output here: https://pastebin.com/raw/jGbLPjxF

Trac metadata

Trac field	Value
Version	8.4.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Build System
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	ezyang, nh2
Operating system
Architecture

changed milestone to %8.8.1

changed weight to 5

added Tbug Trac import labels

ezyang__ from IRC:

ok, I think I agree with your diagnosis

one of the problems with warning in the default package mode (without -hide-all-packages) is that, in most databases, there are lots of inconsistent versions of things, so it would be warning basically all the time

so you'd have to implement this after you handled imports; THEN check that the transitive closures of packages make sense

The new Hadrian build system has been merged. Relabeling the tickets concerning the legacy make build system to prevent confusion.

Trac metadata

Trac field	Value
Component	Build System → Build System (make)

changed milestone to %8.10.1

Bumping milestones of low-priority tickets.

added Pnormal label

changed milestone to %9.0.1

changed milestone to %9.2.1

This will not be fixed in time for %9.2.1

changed milestone to %9.4.1

As you point out, it is a supported configuration to depend on two different versions of the same package

When things break

1. If you try and combine a function from one package
2. Cabal will prevent this from happening by only presenting a plan

Anyway, I think the proximal issue is fixed because now only the directly requested packages are passed to the linker rather than the transitive closure of packages (so the linker/GHC should agree on what is visible).

closed