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

[Ketil Malde]

"Claus Reinke" <claus.reinke at talk21.com> writes:

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

Me too.  This is not a criticism nor endorsement of any particular
scheme, just a vote in favor of having a - one, single, universal -
scheme. 


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

You need a way to specify "foo > 1.2 && foo < 2", which is a
suggestion that was tossed around here recently.   Also, you'd need
foo 1.x for x>=2 to be available after foo-2.0 arrives. 

'base' aside, I don't think we want a system that requires us to
rename a library any time incompatible changes are introduced.

The major/minor scheme has worked nicely for .so for ages.  I'd like
to make the additional suggestion that a major version number of 0
means no compatibility guarantees. 

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

Much like 'fps', now known as 'bytestring', no?  I had some problems
finding it, true, but the upside is that old stuff is free to
reference fps until I can get around to test and update things.

> 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

Scrap cabal in favor of 'ghc --make'? :-)  Seriously though, how hard
would it be to automatically generate a (suggested) build-depends from
ghc --make? 

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants