16.10.2015, 05:38, "Magnus Therning" <mag...@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. _______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/arch-haskell