Skip to Content.
Sympa Menu

sm-commit - Re: [SM-Commit] GIT changes to master grimoire by Lalo Martins (7509530c08c82b1120cb1cd7ac28581679948ae8)

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: Alexander Tsamutali <astsmtl AT gmail.com>(by way of Alexander Tsamutali <astsmtl AT gmail.com>)
  • To: "Lalo Martins" <lalo AT sourcemage.org>
  • Subject: Re: [SM-Commit] GIT changes to master grimoire by Lalo Martins (7509530c08c82b1120cb1cd7ac28581679948ae8)
  • Date: Sat, 27 Oct 2007 16:29:09 +0500
  • Resent-date: Sun, 28 Oct 2007 10:58:59 +0500
  • Resent-from: Alexander Tsamutali <astsmtl AT gmail.com>
  • Resent-to: sm-commit AT lists.ibiblio.org

В Sat, 27 Oct 2007 17:00:31 +0800
"Lalo Martins" <lalo AT sourcemage.org> пишет:

> Well, the "other" solution is to fix dependencies of haskell apps --
> eg darcs.

Seems like this is the best we can do for now.

> What seems to be the correct solution for me is to add "virtual"
> (PROVIDES) spells for each lib that comes built-in with ghc-bin, then
> use those for darcs etc (so it would depend on HASKELL_MTL which would
> be provided by either haskell_mtl or ghc-bin). Otherwise, the way it
> is now, if I choose ghc-bin for darcs, it ends up trying to install
> both ghc and ghc-bin...

This solution has it's drawbacks. First of all someone should inspect
every binary release, because the list of included libraries can
change. Second, this approach doesn't prevent our users from shooting
itself in the foot. They can choose ghc-bin as a provider of GHC, and
haskell-mtl as a provider of HASKELL_MTL. This will lead to the same bad
situation. And third, I don't think that ghc-bin from
z-rejected should affect out main grimoire so badly.

OTOH ghc-bin is useful when you just want to use darcs or other
application which depends on ghc. Building ghc from sources takes a
fair amount of time, and if you cast ghc for the first time, you still
need to download 40Mb ghc-bin to build 4Mb ghc.

That said, i think we need to change GHC dependencies to ghc and leave
ghc-bin conflicting with ghc until a better solution is found. Any
objections?

> Or in other words: the situation with my changes is "incorrect", the
> situation without them was broken.

Agree. I'm trying to resolve this ASAP.

--
Alexander Tsamutali




Archive powered by MHonArc 2.6.24.

Top of Page