On Mon, Apr 26, 2010 at 19:38, Ivan Lazar Miljenovic wrote:

Bjorn Buckwalter writes:

...

Why does cabal seem to prefer base-3.0.3.2 over base-4.2.0.0 when installing packages with an unqualified base requirement? Example:

You mean cabal-install rather than Cabal.  The reason that base-3 is chosen is because many of these old libraries won't build with base-4; as such, if no upper bound restriction is found on the base package then base-3 is chosen as it is more likely to work than base-4 (there were a _lot_ of breakages when base-4 first came out with 6.10.1).

I see, I guess that's pragmatic although the deprecation warning is unfortunate. (I'm aware of the cabal-install versus Cabal distinction, but I understand that cabal-install uses Cabal to resolve dependencies; thus I assumed Cabal was the culprit.) Thanks, Bjorn

...

$ cabal install -v fad --reinstall [snip] Resolving dependencies... selecting fad-1.0 (hackage) selecting base-3.0.3.2 (installed) and 4.2.0.0 (installed) and discarding syb-0.1.0.0, 0.1.0.1, 0.1.0.2, 0.1.0.3, 0.2 and 0.2.1 [snip] Configuring fad-1.0... Dependency base ==3.0.3.2: using base-3.0.3.2 [snip] [1 of 1] Compiling Numeric.FAD      ( Numeric/FAD.hs, dist/build/Numeric/FAD.o )

Numeric/FAD.hs:1:0:     Warning: Module `Prelude' is deprecated:                You are using the old package `base' version 3.x.                Future GHC versions will not support base version 3.x. You                should update your code to use the new base version 4.x. [snip]

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On Mon, Apr 26, 2010 at 20:07, Ivan Lazar Miljenovic wrote:

Bjorn Buckwalter writes:

...

On Mon, Apr 26, 2010 at 19:38, Ivan Lazar Miljenovic wrote:

...

Bjorn Buckwalter writes:

...

Why does cabal seem to prefer base-3.0.3.2 over base-4.2.0.0 when installing packages with an unqualified base requirement? Example:

[snip]

The reason that base-3 is chosen is because many of these old libraries won't build with base-4; as such, if no upper bound restriction is found on the base package then base-3 is chosen as it is more likely to work than base-4 (there were a _lot_ of breakages when base-4 first came out with 6.10.1).

I see, I guess that's pragmatic although the deprecation warning is unfortunate.

The deprecation warning is due to GHC 6.12; this is a not-so-subtle hint to package maintainers to fix their code up, and to users to poke the maintainers of packages they use to do so!

Understood, but in this case the warning seems misdirected since fad does not restrict itself to base-3.*... So what would be the fix, to set an upper bound on base? Is the general recommendation that all packages should specify upper bounds on all dependencies (if so why doesn't Cabal tell us?)? I can see that this would make some sense as a package might be broken by an API change in its dependencies. On the other hand I can also see it causing headaches occasionally... Thanks, Bjorn

Bjorn Buckwalter writes:

So what would be the fix, to set an upper bound on base?

The fix is to have the maintainer check whether or not the package builds with base-4 (you can do this the old manual way using runhaskell Setup.hs). If it does, then specify that it does so, e.g.: base < 5 The upper bound is needed (and Hackage now enforces this) because too many packages have this same problem: the maintainers blindly assume that the package will build for all time, and then it dies the next time a new major version of the base package is released. Note that some people cheat by having dependencies like "base < 10" as Hackage will accept this because there is indeed an upper bound, but this just causes problems in the future (Don Stewart had "base < 5" for a release of ghc-core which then failed to build with base-4).

Is the general recommendation that all packages should specify upper bounds on all dependencies (if so why doesn't Cabal tell us?)?

This is the eventual goal and is why Duncan Coutts is pushing the Package Versioning Policy (http://www.haskell.org/haskellwiki/Package_versioning_policy) as you can tell from the version (if it is followed correctly) when the API has changed in a backwards-incompatible fashion. At the moment, however, Hackage - not Cabal - enforces the requirement on the base package for all new packages uploaded. This isn't made compulsory for all package dependencies as 1) it is base dependencies that typically cause most of the breakages and 2) not all packages follow the PVP and thus doing this doesn't always make sense (e.g. some packages use a date-based versioning system for some reason).

I can see that this would make some sense as a package might be broken by an API change in its dependencies. On the other hand I can also see it causing headaches occasionally...

Right, see the recent thread started by John Goerzon "The instability of Haskell libraries" which is in part to do with this problem. At the moment when a dependency has a major version update but is still buildable by your package you have to create a new release to let it use that updated dependency, which is a pain and isn't always done promptly by maintainers. Possibly the best way towards fixing this is the proposal to take the Cabal files outside of the tarballs and distribute them separately; that way they can be edited without affecting the tarball in question (thus making them even more like Gentoo's ebuild or Arch's PKGBUILD files). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com