haskell / HTTP

Haskell HTTP package

Home Page:http://hackage.haskell.org/package/HTTP

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

GHC 6.12.3 builds

peti opened this issue · comments

Hi, when I try to compile the current release of HTTP with GHC 6.12.3, the configure phase fails because of these errors:

Setup: At least the following dependencies are missing:
array >=0.3.0.2 && <0.6, base >=4.3.0.0 && <4.9

If I just remove these constraints, however, the package compiles just fine:

Configuring HTTP-4000.2.19...
Flags chosen: network-uri=True, warp-tests=True, conduit10=False,
network23=False, warn-as-error=False, mtl1=False
Dependency array -any: using array-0.3.0.1
Dependency base -any: using base-4.2.0.2
Dependency bytestring -any: using bytestring-0.9.1.7
Dependency mtl >=2.0 && <2.3: using mtl-2.2.1
Dependency network ==2.6.*: using network-2.6.0.2
Dependency network-uri ==2.6.*: using network-uri-2.6.0.1
Dependency old-time -any: using old-time-1.0.0.5
Dependency parsec -any: using parsec-3.1.8

Is there any hidden problem with the old base and array libraries that I should be aware of? Or is it possible that the specified version constraints are just too narrow?

It's a deliberate change because I don't want to support GHC<7.0 in future - see https://www.haskell.org/pipermail/libraries/2014-September/023665.html - so while it's not explicitly broken now, it might do so in future without warning.

I'm happy to discuss it if there's a specific need for this (particularly as I use the nix ghc packages to test with!) but generally I'd suggest using an old version of the library with such an old compiler.

We could use an older version, of course. I guess I'd rather like to avoid that because then I'll run into some other library that doesn't work with a prior version of HTTP, and its author will tell me that HTTP x.y.z is too old and he doesn't want to support it, I should instead use an older version of his library, and so on. Before I know it, I'll re-configure half the package set to get any non-trivial number of packages built.

Anyway, I understand your reasoning. It's no big deal, it's not like many people out there still use GHC 6.x on a daily basis. I try to keep support in Nix mostly because of succeeding at doing that gives me intellectual gratification.