Bug in the handling of wired-in packages (like template-haskell)

[simonmar]

If you install an older version of a wired-in package (e.g. template-haskell) and then try to use it, GHC will use the newer one as the "wired-in" package rather than the older one.

This happened when trying to build aeson-0.4.0.0 with ghc 7.4: aeson requires template-haskell-2.6.0.0, but GHC ships with 2.7.0.0. Cabal installed template-haskell-2.6.0.0, but while building aeson against it we get:

Data/Aeson/TH.hs:181:1:
    Bad interface file: /Users/tibbe/.cabal/lib/template-haskell-2.6.0.0/ghc-7.4.0.20111213/Language/Haskell/TH.hi
        Something is amiss; requested module  template-haskell-2.6.0.0:Language.Haskell.TH differs from name found in the interface file template-haskell:Language.Haskell.TH

the bug is that findWiredInPackage has picked template-haskell-2.7.0.0 to be the wired-in package:

wired-in package template-haskell mapped to template-haskell-2.7.0.0-inplace

whereas we wanted to use template-haskell-2.6.0.0.

Not immediately obvious what the fix should be, so I'm making a ticket for this. The workaround is to update the dependency in aeson to allow template-haskell-2.7.0.0.

[tibbe]

Just to clarify the actual failure case:

• aeson-0.4.0.0 requires template-haskell >= 2.4,
• snap-server-0.7.1 requires template-haskell >= 2.2 && < 2.7,
• template-haskell-2.6.0.0 therefore gets selected, and
• the compilation (of aeson) fails as in the ticket description.

[bgamari]

Has there been any progress on this? The current release of fc-labels also seems to carry a dependency on template-haskell 2.6.0.0.

[bgamari]

Oops, never mind concerning fclabels.

[simonmar]

I'm going to close this. It just doesn't work to have multiple versions of a wired-in package, all kinds of things could go wrong.

We currently allow multiple versions to exist, but only the latest is considered to be "the" wired-in one. This was to make it possible to have both base-3 and base-4 coexisting, where base-3 depended on base-4. This doesn't apply in the above template-haskell example, where the two packages are really independent.

I think the right fix is just to not do this, and if I understand correctly the latest version of Cabal is better at avoiding it anyway.