GHC MinGW distribution

Alexander Berntsen alexander at
Tue Jun 10 09:37:51 UTC 2014

Hash: SHA256

On 10/06/14 10:42, Herbert Valerio Riedel wrote:
> Btw, there's just one thing I'm worried about with keeping those
> large MinGW binary tarballs in a Git repo:
> The Git repo will grow monotonically with each new compressed 
> .tar.{bz2,lzma,gz,...} added, with little opportunity for Git to
> detect shared bitstreams. So effectively each MiB of binary-data
> added will effectively grow the Git repo everyone will have to
> clone (even if only the latest MinGW for a specific 32/64-bit
> platform is desired) by that same amount.
> Right now, cloning the ghc-tarballs.git repo requires to fetch
> ~130MiB.
> Can't we simply put the tarballs in a plain HTTP folder on 
>, and store a list (or rather a shell script)
> of URLs+checksums in ghc.git to retrieve the tarballs if needed on
> demand?
I agree with this. Having binaries in git is really dirty for several
reasons. It would be cleaner to retrieve src and build it through the
build system. But I suspect Windows people don't commonly do this(?),
so checking for the binaries, and if they're not found, downloading
them (or asking the user to fix their paths) would likely suffice. The
binaries should in any event not be in git...

And as hvr points out, tarballs are a mess by themselves regardless of
whether they contain binaries or source, because git (rightly) thinks
they are blobs.

Apologies for any assumptions made in this email that don't hold true
- -- I do not use Windows.
- -- 
alexander at
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the ghc-devs mailing list