[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
ketil+haskell at ii.uib.no
Mon Oct 15 10:10:18 EDT 2007
"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 -
> 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
If I haven't seen further, it is by standing in the footprints of giants
More information about the Haskell-Cafe