The bootstrap.sh script has to go
Johan Tibell
johan.tibell at gmail.com
Thu Jan 1 16:43:44 UTC 2015
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 <hvr at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20150101/1afe552e/attachment.html>
More information about the cabal-devel
mailing list