I have a pull request here for review: https://github.com/haskell/cabal/pull/2312
On 1 January 2015 at 18:43, Johan Tibell <johan.tib...@gmail.com> wrote: > See https://github.com/haskell/cabal/issues/2310 for a continuation of > the sad bootstrap.sh saga. > > On Thu, Jan 1, 2015 at 6:43 AM, Herbert Valerio Riedel <h...@gnu.org> > wrote: > >> On 2014-12-30 at 21:23:19 +0100, Jake Wheat wrote: >> >> [...] >> >> > Simplify the bootstrap.sh process: >> > >> > * always use a fixed set of versions of packages for the dependencies >> >> For me, the primary use-case of `bootstrap.sh` is to be able to build a >> matching `cabal-install` executable for a given major GHC version w/o >> requiring having an existing cabal-install executable compatible w/ the >> GHC version I'm trying to bootstrap cabal-install with. (If I had an >> older `cabal-install` executable, I would use that to bootstrap the new >> one) >> >> So, if a given cabal-install's bootstrap.sh would only support >> bootstrapping via its associated GHC major version >> (e.g. cabal-install-1.22.x would require GHC 7.10.x) then I guess the >> bootstrap.sh wouldn't need to perform any significant package version >> resolving, and could just use such a single fixed set of versions (and >> preferably in a sandbox to ignore any user pkg-db) as you seem to >> propose. >> >> >> Alternatively, GHC could start bundling cabal-install, which would IMHO >> eliminate the need for a bootstrap.sh in the first place (but we had >> that discussion already, and it would also require to pull >> cabal-install's dependencies into the GHC distribution, while OTOH GHC >> is trying to avoid acquiring additional build dependencies...) >> >> Cheers, >> hvr >> > >
_______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
