Breakage with 6.10
Quick summary of the latest hackage state, now hslogger has been amended. x86_64/linux/ghc-6.10/cabal-install 0.6/Cabal 1.6 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 71 DependencyFailed 138 BuildFailed 447 InstallOk So you can see that DependencyFailed is down 30, thanks to hslogger now working. InstallOk is up about 23. A breakdown of the remaing causes for DependencyFailed, 2 Win32-2.1.0.0 2 Yampa-0.9.2.2 2 hint-0.2.4.1 2 hsdns-1.3 2 plugins-1.3 3 pandoc-1.0.0.1 3 stringtable-atom-0.0.4 4 TypeCompose-0.5 4 hsql-1.7 4 hsx-0.4.4 5 hxt-8.1.0 6 HAppS-Data-0.9.2.1 6 arrows-0.4 6 wxcore-0.10.3 The main thing to fix there is 'arrows', an extra lib, we'll bump that. arrows fails due to: [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:24:29: Module `Control.Arrow' does not export `pure' Even though cabal-install decided to use base-3.0.3.0 So that means base-3 is *not* exporting quite the same interface as last time. Were we aware of this? -- Don
On Fri, 2008-10-10 at 15:34 -0700, Don Stewart wrote:
arrows fails due to:
[ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o )
Control/Arrow/Transformer/CoState.hs:24:29: Module `Control.Arrow' does not export `pure'
Even though cabal-install decided to use base-3.0.3.0
So that means base-3 is *not* exporting quite the same interface as last time. Were we aware of this?
Note that this means that base-3 should have the version number 3.1.x.y because there is at least one incompatible api change. We're promoting the versioning policy so we need to follow it ourselves in our base libs. On this issue, we've discussed before that packages should be able to opt-into the versioning policy and that if they do we can have our tools suggest that dependencies on such packages should take a particular form. For example depending on and api version ==1.1.* and not upward open ranges, or mistakes like parsec <= 2.1.0.0. There's not time to implement these suggestions in the tools for 6.10 however we do have the opportunity to annotate the packages that we believe do follow the versioning policy. We can then get our tools make use of this information in the coming months. So my suggestion is that in time for 6.10.1 we add something like the following to the .cabal files for all the core and extra packages: x-follows-version-policy: This is free. It doesn't involve any api changes in Cabal or anything else. All such "x-" extension fields are allowed by cabal and collected into a name/value pair list. If it seems to work out then we can make it a proper field (and at that time we can argue what colour we should paint it). Sound sensible? We can send patches to add this to the core + extra packages. I think it'd be good to do this now because while the base 3 - 4 thing has gone fairly well this time, future changes would be much easier if we were using more sensible dependency constraints. I think the best way to communicate that to developers is through warnings generated by their tools. Yes that's right, cabal-install is a channel for package QA propaganda. Duncan
On Fri, Oct 10, 2008 at 03:54:07PM -0700, Duncan Coutts wrote:
On Fri, 2008-10-10 at 15:34 -0700, Don Stewart wrote:
arrows fails due to:
[ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o )
Control/Arrow/Transformer/CoState.hs:24:29: Module `Control.Arrow' does not export `pure'
Even though cabal-install decided to use base-3.0.3.0
So that means base-3 is *not* exporting quite the same interface as last time. Were we aware of this?
Note that this means that base-3 should have the version number 3.1.x.y because there is at least one incompatible api change. We're promoting the versioning policy so we need to follow it ourselves in our base libs.
I don't think that that really helps. If you're going to depend on base 3.1, you might as well just depend on base 4 and be more future-proof. The base-compat package needs to claim to have the same API as the old base, because the point is that things just keep on working (except in the few cases, like the Arrow split, where that isn't possible). Thanks Ian
Ian Lynagh wrote:
On Fri, Oct 10, 2008 at 03:54:07PM -0700, Duncan Coutts wrote:
arrows fails due to:
[ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o )
Control/Arrow/Transformer/CoState.hs:24:29: Module `Control.Arrow' does not export `pure'
Even though cabal-install decided to use base-3.0.3.0
So that means base-3 is *not* exporting quite the same interface as last time. Were we aware of this? Note that this means that base-3 should have the version number 3.1.x.y because there is at least one incompatible api change. We're promoting
On Fri, 2008-10-10 at 15:34 -0700, Don Stewart wrote: the versioning policy so we need to follow it ourselves in our base libs.
I don't think that that really helps. If you're going to depend on base 3.1, you might as well just depend on base 4 and be more future-proof. The base-compat package needs to claim to have the same API as the old base, because the point is that things just keep on working (except in the few cases, like the Arrow split, where that isn't possible).
Hmm, this is quite annoying. We simply *can't* provide the same API as base-3.0.2 without defining a new Arrow class, and that would kill compatibility with base-4. On the other hand, we did know this could happen (changes to datatypes also cause the same problem), it's the tradeoff with trying to provide base-3 as a compatibility layer over base-4. So the options are: * if we are honest and call it base-3.1, then everyone else has to lie and use dependencies like base==4.*. If they use dependencies like base==4.0, which are more correct, then these packages will break in GHC 6.12 if we have to ship base-4.1 rather than 4.0. * we lie (a bit) and call it base-3.0.3. so the total amount of dishonesty is reduced if we pick the second option :-) Perhaps we've found a use for the second digit of the major version number. Cheers, Simon
participants (4)
-
Don Stewart -
Duncan Coutts -
Ian Lynagh -
Simon Marlow