- if you provide a 'base' configuration that pulls in the stuff that used to be in base, the package will work
I don't know of a way to do that. The name of the package is baked into the object files at compile time, so you can't use the same compiled module in more than one package.
i've been wrong about this before, so check before you believe,-) but here is a hack i arrived at the last time we discussed this: [using time:Data.Time as a small example; ghc-6.6.1] 1. create, build, and install a package QTime, with default Setup.hs -- QTime.cabal Name: QTime Version: 0.1 Build-depends: base, time Exposed-modules: QTime.Data.Time -- QTime/Data/Time.hs module QTime.Data.Time(module Data.Time) where import Data.Time 2. create, build, and install a package Time2, with default Setup.hs -- Time2.cabal Name: Time2 Version: 0.1 Build-depends: base, QTime Exposed-modules: Data.Time -- Data/Time.hs module Data.Time(module QTime.Data.Time) where import QTime.Data.Time 3. write and build a client module -- Main.hs import Data.Time main = print =<< getCurrentTime $ ghc -hide-all-packages -package base Main.hs Main.hs:1:0: Failed to load interface for `Data.Time': it is a member of package Time2-0.1, which is hidden $ ghc -hide-all-packages -package base -package Time2 Main.hs $ ./main.exe 2007-10-16 11:09:05.859375 UTC $ rm main.exe Main.hi Main.o $ ghc -hide-all-packages -package base -package time Main.hs $ ./main.exe 2007-10-16 11:09:29.34375 UTC as i said, i've misinterpreted such symptoms before, but it seems to me that Time2's Data.Time acts as a drop-in replacement for time's Data.Time here. doesn't it? it is rather tedious, having to do something for every module in the package, twice (once to get a package-qualified name that differs from the original name, the second time to re-expose it under its original name), but that could be automated. and there would be an extra QBase package. but until cabal supports such renamings directly, it might be a workaround for the current base issue? claus