[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4

[Claus Reinke]

>> but calling "split-base" "base" goes directly against all basic 
>> assumptions of all packages depending on "base".
> 
> The new base will have a new version number.  There is no expectation of 
> compatibility when the major version is bumped; but we do have an informal 
> convention that minor version bumps only add functionality, and sub-minor 
> version bumps don't change the API at all.

if this is the "official" interpretation of cabal package version numbers,
could it please be made explicit in a prominent position in the cabal docs?

of course, i have absolutely no idea how to write stable packages under
this interpretation. and the examples in the cabal docs do not explain this,
either (neither "bar" nor "foo > 1.2" are any good under this interpretation).
 
> 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

why do you omit the most popular (because most obvious to users) option?

- if base remains what it is and a new package is created providing the rest
    of base after the split, then every user is happy (that it is currently hard
    to implement this by reexporting the split packages as base is no excuse)
 
> In the design we've chosen, some packages continue to work without change.
> 
> Specifying a dependency on a package without giving an explicit version 
> range is a bet: sometimes it wins, sometimes it doesn't.  The nice thing is 
> that we have most of our packages in one place, so we can easily test which 
> ones are broken and notify the maintainers and/or fix them.

sorry, i don't want to turn package management into a betting system.
and i don't see how knowing how much is broken (so cabal can now
only work with central hackage?) is any better than avoiding such 
breakage in the first place.

cabal is fairly new and still under development, so there is no need to
build in assumptions that are sure to cause grief later (and indeed are
doing so already).
 
> Another reason not to change the name of 'base' is that there would be a 
> significant cost to doing so: the name is everywhere, not just in the 
> source code of GHC and its tools, but wiki pages, documentation, and so on. 

but the name that is everywhere does not stand for what the new version
provides! any place that is currently referring to 'base' will have to be
inspected to check whether it will or will not work with the reduced
base package. and any place that is known to work with the new
base package might as well make that clear, by using a different name.

>  Yes I know we've changed other names - very little in packaging is clear-cut.

how about using a provides/expects system instead of betting on
version numbers? if a package X expects the functionality of base-1.0,
cabal would go looking not for packages that happen to share the name,
but for packages that provide the functionality. base-not-1.0 would
know that it doesn't do that. and if there is no single package that
reexports the functionality of base-1.0, cabal could even try to consult
multiple packages to make ends meet (provided that someone told it
that 'expects: base' can be met by 'provides: rest-base containers ..').

claus