Hey,

On 03/09/10 22:22, david fries wrote:
> You both pointed out that installing ports which are already part of
> lang/ghc may cause problems. However I don't see why. Take the
> network module, for example.

Let me help you then.  I installed your port right from the PR [1], and let us assume that I have the following Haskell source (Networking.hs):


module Networking where

import Data.ByteString.Lazy
import Data.Maybe
import Network.HTTP
import Network.Stream
import Network.URI

getBinary :: String -> IO ByteString
getBinary url = do
  uri <- return $ fromJust $ parseURI url
  rsp <- simpleHTTP $ request uri
  getResponseBody rsp
    where
      request uri = Request
        { rqURI = uri
        , rqMethod = GET
        , rqHeaders = []
        , rqBody = empty }


When I try to compile it (`ghc --make Networking.hs`) I got this:

Networking.hs:12:30:
    Couldn't match expected type `network-2.2.1.2:Network.URI.URI'
           against inferred type `URI'
    In the first argument of `request', namely `uri'
    In the second argument of `($)', namely `request uri'
    In a stmt of a 'do' expression: rsp <- simpleHTTP $ request uri


However, the following thing could help:

$ ghc --make Networking.hs -package network-2.2.1.2


But that is a really ugly workaround, I think.

For your information, the GHC shipped with Haskell Platform (on Windows, at least) *does not* include network-2.2.1.2, only network-2.2.1.4, so there are no duplicate network packages installed.  To achieve the same result with your approach (lang/ghc + "devel/hs-network2214"), we would need to fumble with the files that lang/ghc installed before.

Perhaps there could be some option in lang/ghc/Makefile to set whether we want to install GHC as part (actually SLAVE) of Haskell Platform or not, so we can replace the corresponding modules for sake of conformity to the specification. That might be a solution, and it would not even require a separate port or anything else.


> A potential network-2.2.1.4 port would be installed by itself in
> /usr/local/lib/network-2.2.1.4 and its haddock documentation is also
> in a separate directory.

Well, your PR contains the port of network-2.2.1.7 :P


> ghc-pkg list shows two different installed network versions, but GHC
> & Cabal have been designed to handle multiple module versions.

Can it do that automatically so I was wrong above?


> So I don't see what the problem is. Maybe someone could elaborate on
> that a little bit more. So that I can come up with an acceptable
> solution.

I hope now you see my concerns.  But I described a potential solution.


> Frankly, the issue of version dependencies is pretty important to
> me. The current happy go lucky way of just have the latest version of
> a module in the portstree is insufficient. I'm sure I'm not the first
> one to bump into this issue. Right? If I had my way, I would
> explicitly put the version in the name suffix.

I agree on that, but can you give some examples on when it is better to have not the latest version in the ports tree (other than this HP issue)?

A problem could be that the ports tree cannot handle versions so elegantly as Cabal does (as far as I know): there is no way to specify an upper limit for the version of a dependency, i. e. x <= n, but I might be wrong.


Hope that helps,
:g

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/143649