On Sat, 2009-11-28 at 16:37 +0000, Duncan Coutts wrote:
package authors,
I'm preparing to release a new version of Cabal. This is the one that will come with ghc-6.12.
Another cause of breakage is due to a change in semantics of the treatment of dependencies of disabled components. Consider: Library [...] exposed-modules: [...] Happstack.Util.Testing, [...] -- The Happstack.Util.Testing module uses the HUnit package -- the library does not specify build-depends: HUnit -- on the other hand, the executable does, but it's disabled by default Executable happstack-util-tests Main-Is: Test.hs GHC-Options: -threaded Build-depends: HUnit hs-source-dirs: tests, src if flag(tests) Buildable: True Build-Depends: network else Buildable: False Now in Cabal-1.6 this builds, despite the fact that only the test program depends on HUnit and that test program is disabled. This is because Cabal used to take the dependencies of each component (exes, libs) and apply the union of them to all components. There are two changes in behaviour in Cabal-1.8, one is opt-in so that we don't break too many packages. The first is that each components dependencies are for that component alone. This is opt-in. You get the new behaviour if you use cabal-version: >=1.8. The other is that we omit dependencies of components that will not be built. This means we drag in fewer dependencies generally. However in this case it exposes the fact that the library actually needs a dependency that is only used by another component, and one that is disabled by default. On balance I think we don't want to make the second change opt-in, that the benefit of not dragging in the extra dependencies for most packages outweighs the couple packages that were relying on this corner case. I did build a large proportion of hackage and happstack-util-0.3.2 is the only one I found that is broken by this change. I expect the happstack maintainers can easily get a point release out. Duncan