Udo Stenzel wrote:
Simon Marlow wrote:
So a package that depends on 'base' (with no upper version bound) *might* be broken in GHC 6.8.1, depending on which modules from base it actually uses. Let's look at the other options:
- if we rename base, the package will *definitely* be broken
- if the package specified an upper bound on its base dependency, it will *definitely* be broken
- 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 hate betting, but I'd like to know if...
- it is okay to give GHC 6.4/6.6 a castrated configuration of the base libraries to remove the conflict with recent ByteString?
Sure, that's what I suggested before. Moving modules of an existing package from 'exposed-modules' to 'hidden-modules' is safe (I wouldn't recommend removing them entirely).
- when GHC 6.8 comes out containing base-3, will it be possible to additionally install something calling base-2 with both being available to packages?
In theory yes - the system was designed to allow this. In practice we've never tried it, and base-2 might not compile unmodified with GHC 6.8.
- If so, will existing Cabal packages automatically pick up the compatible base-2 despite base-3 being available?
Only if they specify an upper bound on the base dependency, which most don't, but it's an easy change to make. Cheers, Simon