[arch-haskell] ghc-vis

[stef204]

16.10.2015, 05:38, "Magnus Therning" <magnus at therning.org>:

>
> I've just pushed up a new version to Hackage with that change included.
> It'll get to `[haskell-core]` soon-ish.
>
Thanks a lot. Got it and upgraded.

>
> Maybe `build` is badly named, it doesn't *perform* a build, it only
> outputs an order for a successful build.
>

It is just fine the way it is; all one has to do is read the doc or use --help , nothing wrong with the name, it was clear all along it addresses the order.
I just thought I might not have used it properly and may not have been installing in the proper order, making it more difficult to resolve the dep chain.

>
> I usually operate on *all added packages* at once through the whole
> upgrade/add process.
>

Here above ^^ I am not completely sure what you mean....
Are you referring to using just one single pacman -S command with all of the packages needing installation at once?

>
> That is completely correct. `pacman -Su` won't let you take your system
> into an inconsistent state though.
>

Yes, a point in favor of the cblrepo + pacman approach.

> I'm currently experimenting
> with a split package for stack though. 

This should be interesting.

> Also, I've found that pacman is
> *really* good with handling packages, so having lots of them isn't a big
> issue. 

Agreed, pacman is indeed *really* good and it helps to know one can always reverse whatever was installed/done previously

> Also, if you want to clean out your system you can use `pacman
> -Rncs ghc` to do it (you'll be left with exe-only packages, like
>  cblrepo, though).
>

OK, thanks for that info, I guess it all depends on ghc so removing it would remove all haskell packages except binaries..
Hopefully, won't ever come to that.

> You have to make up your own mind on the issue of system-wide vs.
> sandboxes. :-) 
>

Yes. Will consider all of the info you provided and try to decide on best approach, i.e. one which suits me.
  
>>  % cblrepo add aeson,0.8.1.1
>>  Adding aeson 0.8.1.1 would break:
>>    cblrepo : aeson ==0.9.*
>>
>>  How do I get out of the above, if at all possible?
>
> This is due to upstream depending on an old version of `aeson`. You can
> patch the `.cabal` file (have a look in habs `patches` dir). In
> surprisingly many cases you can just bump the upper limit without any
> code changes. In a few cases you'll have to do the work of the upstream
> devs and modify the code too. If that's the case have a look in their
> VCS, I've often found exactly the patch needed already checked in but
> not release, or as an attachment to a ticket.
>

Thanks for this clear explanation. Will follow those steps and try to resolve it.

> Just note that `stack runghci` is marked as "experimental".
>

np, we'll see how it goes.

Thanks a lot for the informative feedback, very pertinent and helpful.