-----BEGIN PGP SIGNED MESSAGE----- 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 http://ghc.haskell.org, 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 alexander@plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlOW0e8ACgkQRtClrXBQc7WzFAD9Fcz+Ur80Dh2wCqrZxGYEABEC QetdlxKC49nCPfLRfwwA/0e4PdVDv6+af7eeHFmUKXf5nDjxPx8ex3i+PpWC/xgL =tE6K -----END PGP SIGNATURE-----