OK. I found cabal-src tool, which solved this perfect. On Wed, Jun 20, 2012 at 9:22 AM, Magicloud Magiclouds <magicloud.magiclo...@gmail.com> wrote: > Hi, > The names here were just placeholder. And I just found out the reason. > Hackage magicloud is local (not from hackage.haskell.org), there is > no its information in cabal INDEX (I assumed so). But this raised > another question, how to reference a local hackage in .cabal. So the > solver could use the dependencies originally defined but not the > binary compiled (which dependencies are fixed)? > > On Tue, Jun 19, 2012 at 5:50 PM, Andres Löh <andres.l...@googlemail.com> > wrote: >> Hi. >> >>> Hackage A depends on magicloud (any) and container (0.4.0.0), and >>> hackage magicloud depends on container (any). >>> Now I've installed magicloud, using container 0.5.0.0. Then I failed >>> to install A, with any solver. >>> >>> So the solvers are using the status that is installed, not the >>> definitions from original hackages? >> >> Could you please provide me with something I can reproduce? I'm not >> sure what you mean by "A" or "magicloud". Are you saying they have no >> further dependencies except for the one on container? If you could >> just state which concrete packages have caused the problem, it'd >> probably be easier. The trace output of the modular solver with -v3 >> would also help (send it to me personally if it's too long). >> >> Thanks. >> >> Andres > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com.
-- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe