In all this discussion on configurations I think I'm not getting over my main point about why we can't go for the 'easy' option of allowing package 'available' tests everywhere. Let me list a few reasons and then expand on them. 1. it often doesn't mean what you want 2. it allows auto-use deps 3. it makes life hard for distros and cabal-get 4. it makes the install order significant So, 1: it often doesn't mean what you want configuration: available(foo >= 2) cpp-options: -Denable_cool_feature There's no necessary relation between what packages are available in the environment and the one(s) that the package is going to be built against. So the above will fail if we actually build with foo-1 but foo-2 is available. What's worse is that it will likely work on the developers machine but fail on the users machine. 2: it allows auto-use deps An auto-use dep is one where we add an extra dependency on a package just because it's available. This is bad for a number of reasons. It means you cannot build a package on one machine and distribute it on another if that other doesn't have the optional dependency (the only way to do it would be to delete the optional package on the build machine). Distros do not support this kind of dep. It mostly makes no sense in binary-based distros and is actively banned in source distros like gentoo: http://www.gentoo.org/proj/en/qa/automagic.xml Indeed this kind of dependency cannot even be expressed in gentoo's dependency syntax. 3: it makes life hard for distros and cabal-get So how is cabal-get supposed to decide before hand all the dependencies that are needed to install a set of packages. Suppose we want to install A and B, but B checks if A is available and if so depends on C. So cabal-get needs to figure out the order it's going to install things and forward-propagate the set of installed packages at that time to figure out if an extra dep on C will be needed or not. As I mentioned already, many distros cannot express these kinds of automatic optional dependencies and so they will have to be turned into hard dependencies or eliminated by the distro package authors. This is a lot more work for them than if the translation is straightforward and can be automated. 4: it makes the install order significant in the above example, we only need C if we install A then B. If we install B then A, then we do not need C. So the order that we install becomes significant. We might be able to make cabal-get always choose one order (at the expense of preventing parallel builds) but that's not necessarily the same order that a distro package manager will pick. This isn't that bad but it's not exactly nice or intuitive. Duncan