> I don’t know GHC, but apparently it can be bootstrapped from
> intermediate generated C files:

>   http://www.haskell.org/ghc/docs/6.4.1/html/building/sec-porting-ghc.html

> Wouldn’t that be better than fiddling with binaries out-of-band?

The recent versions of the compiler don’t support this.  So you have to
use the old version.  I’ve spent four hours on this and didn’t even get
to the intermediate C files (that’s the first step).  The compiler
depends on the old libraries, so you have to downgrade.  That’s the main
difficulty.

Also, you can’t build GHC 7.6.3 using GHC 6.4.1.  Users would have to
build several compilers any time they want the latest version.  That may
take more than six hours (or even longer) on an average machine.

So I’d prefer to avoid this if it’s possible.

>> 1. We’d have to host the binaries (step 2) somewhere and repeat the
>>    process whenever the hash of ‘/bin/sh’ changes.  How often will this
>>    happen?

> The hash of /bin/sh?  Where did you see /bin/sh?  :-)

I meant this one:

scheme@(guile-user)> ,use (guix build utils)
scheme@(guile-user)> (which "sh")
$1 = "/nix/var/nix/profiles/default/guix-profile/bin/sh"
scheme@(guile-user)> (readlink $1)
$2 = "/nix/store/fzcdfwyyin5dr7finlaq2kph396nrlli-bash-4.2/bin/sh"

How often may the hash change?  In other words, what does Bash use to
“source” the hash function?  Will it happen whenever you merge
‘core-updates’?

> The ‘uri’ argument can be a list:

>   (origin
>     (method url-fetch)
>     (uri (list "http://..." "file://..."))
>     (sha256 ...))

> However, ‘url-fetch’ doesn’t support file://.

> The other option would be to allow ‘source’ to be a list; that’s easily
> implemented, just not done yet.

Thanks, I’ll look into it.