[Haskell] Re: Trying to install binary-0.4
simonmarhaskell at gmail.com
Mon Oct 29 07:24:53 EDT 2007
Simon Marlow wrote:
> Probably it could be made clearer. In 4.2 the idea is that instead of
> base-2.0 ==> base-3.0 + directory-1.0 + array-1.0 + ...
> you would replace
> base-2.0 ==> newbase-1.0 + directory-1.0 + array-1.0 + ...
> and additionally have a package base-3.0 that re-exports the whole of
> (newbase + directory + array + ...).
There's another alternative, that Simon PJ pointed out to me this morning.
Actually I think this is rather nice, as it solves the problem of having
to rename base for each split.
Let's suppose that in GHC 6.10 we want to split some modules from base
again (highly likely). So we make this change, for example:
base-3.0 ===> base-4.0 + concurrent-1.0 + generics-1.0
note that the new, smaller, base is called base-4.0.
Then, we provide a wrapper package base-3.1, that re-exports (base-4.0 +
concurrent-1.0 + generics-1.0). Why is it called 3.1, not 3.0? Because
almost certainly by the time GHC 6.10 is released there will be some API
changes in these packages too, and we aren't trying to reproduce the
base-3.0 API exactly (that's proposal 4.1). This amounts to adopting a
convention for the base package that changes in the first component of the
version indicate splits or removal of modules, and changes to the second
component indicate other API changes only.
The idea is that all packages on Hackage will be using precise dependencies
by this point, so they will all have something like
Now, when GHC 6.10 is released, the majority of these packages will build
again if the .cabal file is changed to say
build-depends: base >= 3.0 && <= 3.1
rather than introducing conditional dependencies as was necessary with the
recent base split. In due course, packages can be upgraded to depend on
the new base-4.0.
I'll call this proposal 4.3 and add it to the wiki. It seems like a pretty
good compromise to me.
More information about the Libraries