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

[Simon Marlow]

Claus Reinke wrote:

> 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?

Yes - I think it would be a good idea to make that convention explicit 
somewhere (I'm sure we've talked about it in the past, but I can't remember 
what happened if anything).

However, I'd like to separate it from Cabal.  Cabal provides mechanism not 
policy, regarding version numbers.

> 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).

base >= 2.0 && < 3.0

I believe Cabal is getting (or has got?) some new syntax to make this simpler.

> 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)

Omitted only because it isn't implemented.  Well, it is implemented, on my 
laptop, but I'm not happy with the design yet.

>> 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).

what assumptions does Cabal build in?

>>  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. 

Using the version number convention mentioned earlier, "base-1.0" 
funcionality is provided by base-1.0.* only.  A package can already specify 
that explicitly.

I think what you're asking for is more than that: you want us to provide 
base-1.0, base-2.0 and base-3.0 at the same time, so that old packages 
continue to work without needing to be updated.  That is possible, but much 
more work for the maintainer.  Ultimately when things settle down it might 
make sense to do this kind of thing, but right now I think an easier 
approach is to just fix packages when dependencies change, and to identify 
sets of mutually-compatible packages (we've talked about doing this on 
Hackage before).

Cheers,
	Simon