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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
