[arch-haskell] http-conduit

[Magnus Therning]

On Wed, Oct 3, 2012 at 7:49 PM,  <tam at hiddenrock.com> wrote:
>> That sounds good, it would however be interesting to find out what
>> your criteria is (what you are looking for) and how your tool
>> satisfies them.
>
> A few things:
>
> - The documentation was so sparse, I thought it would be less effort to
>   implement from scratch than try to figure out how the current system worked.
>   In retrospect, I believe I was correct in this, not least because I'm not
>   sufficiently expert at Haskell to efficiently figure out precisely what
>   cabal2arch is doing.

Had you bothered reading the documentation that *does* exist you would
have found out that we don't use cabal2arch to package for ArchHaskell
any longer.

> - cabal2arch treats all cabal dependencies as '=' and does not honor '<=' or
>   '>=' which is a pain in the ass because it requires rebuilding everything
>   when one package version changes.  It's entirely likely there's a good
>   reason for this; I didn't dig in because the idea offends me as it
>   completely undermines the point of libraries in the first place.  So I'm
>   living on the edge with my implementation in this regard.

This is a requirement that comes from how GHC builds and links.  Yes,
you are most definitely living on the edge if you recompile required
packages without also recompiling the packages that require them.

> - cabal2arch uses a hard-coded list of libraries provided by ghc, but this
>   seems redundant due to the Arch ghc package's "provides" (which I assume
>   came to be after cabal2arch was written).

Indeed, and our current tool, cblrepo, has moved that list into an
external database.

> - I don't have a good alternate solution to the hard-coded list of library
>   providers.  I think maintaining this list is far more reasonable than the
>   ghc-provides list, though, because it's specific to the intersection of Arch
>   Linux and Haskell, whereas ghc provides is not.

That is an area where our current tool is lacking.  At the moment that
mapping in handled through patches to the generated PKGBUILDs, which
isn't very elegant at all, but it works.

> - I have probably made some erroneous assumptions here, but given the
>   combination of lack of documentation, lack of response to the mailing list,
>   and my substandard knowledge of Haskell, I figured the best way to solve my
>   problem (ie, to install stuff from hackage I wanted to play with) was to
>   roll my own.  I am not upset at the aforementioned lacks; I enjoy the work
>   and I enjoy the learning; please do not infer any angst from me here.

IMNSHO it is rather simple to do this for a couple of packages.
However, as the set of packages grow it becomes more and more obvious
that some sort of tool support is necessary.  Do you think that what
you put together would allow maintaining a repo of 150+ Haskell
packages by a (very) small group (sometimes so small that it is a
single individual)?

The reason I'm asking is because we've found that cabal2arch isn't
such a tool, but cblrepo comes a bit closer to it.

> As I said previously, I do plan to make my stuff generally available, but I
> haven't had time to add a baseline of polish so that people can actually use
> it relatively autonomously. ;)

Let us know when you've put it out for us to have a look :)

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus