incorrect dependencies for packages with both library and executable in them

[kr.angelov@…]

If you have package which contains both a library and an executable then the dependencies for the compiler library are set to be the union of the dependencies for the executable and the library. For example with the GF package description:

 http://hackage.haskell.org/packages/archive/gf/3.1.6/gf.cabal

'ghc-pkg describe gf' will report:

depends: Win32-2.2.0.1-f796bdb4f71914e9886090422be8f9cb

array-0.3.0.0-dbdf73710a5bd9a534e8bcb2d8c8ee98 base-4.2.0.0-f9f9ffe572130b994c2080b74a5b4e68 bytestring-0.9.1.5-00c16473505de56926118ef2c791fff2 containers-0.3.0.0-409fe3b8f0dda25b98e03716d26be411 directory-1.0.1.0-57db95a03e1d1b3b8c63f3744fe9d297 filepath-1.1.0.3-ccf4622ce5a33fc941fb0fe1e5fa228c haskeline-0.6.2.2-1c1615561ccaeda54ae035ac05fbd790 mtl-1.1.0.2-23ca4de7c573fd4df309067199a40634 old-time-1.0.0.3-31e98cd52d90f145132096c2ac27b2bb pretty-1.0.1.1-2bfa34c699efff7eed4d6297a2dac12d process-1.0.1.2-defcecf2341a38cef42864b527e668bb random-1.0.0.2-156803737564049405b3380fdb96ac75

while the real library dependencies are only base, array, containers, bytestring and random.

[duncan]

This is fixed in Cabal-1.8.

However so that we do not break all the old packages that accidentally depend on this bug, the fixed behaviour is only enabled if your package specifies cabal-version: >= 1.8.

It is unfortunate that we have to conditionally enable this behaviour. Because the bug was around for so long many packages accidentally depend on it. Indeed gf-3.1.6 itself needs fixing! The lib part depends on pretty but does not say so. It's picking it up because it's specified for the gf executable.