build-depends on packages that provide no library

[duncan]

It is possible to list build-depends on packages that have just an executable and no library. Currently the behaviour of cabal-install does not consider this and it will allow such packages to be pulled in as dependencies. It leads to problems however because the non-lib package never gets registered with ghc-pkg and so it leads to re-install loops.

The solution is for cabal-install to not consider exe-only packages to be valid for satisfying a build-depends requirement. It should produce a suitable error message.

Note that it must take into account the posibility that a newer or older version of a package may switch from exe only to exe+lib or just lib, or indeed vica versa.

We should mark exe-only versions of the package as excluded with a reason. Then if the dep is not satisfiable then we can explain why all the excluded ones were excluded (ie due to not exposing a lib).

[kosmikus]

We should look at this again and discuss if the new solver should handle this case. It would certainly be possible, but I'm worried it might lead to unexpected problems.

[kosmikus]

Related to #695.

[kosmikus]

I'm not prepared to add this as an option to the modular solver just yet. In principle, it wouldn't be hard. We could have a configurable option that excludes no-library packages while solving.

The tricky issue is the following: for user-specified goals, we want no-library packages to be available, but *only* if they're not also build-dependencies of other user-specified goals. However, while building the tree, we do not know the complete reverse dependencies of the goal nodes yet. We only have the knowledge for everything above the current node. So we can, for example, say with certainty that a package is a user goal, but we cannot say with certainty that we won't discover that it's a build-dependency of another package later.

This implies that we cannot make the decision whether to exclude no-lib versions of a package or not yet, and knowledge we acquire later can invalidate the path of the tree we're currently on.

While this can also be implemented in the modular solver, it's subtle enough so that I don't want to do it before the 0.14 release.