
16.10.2015, 05:38, "Magnus Therning"
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.