Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#7017 closed task (fixed)

Rethink need for tarballs under "friendly" environment

Reported by: FUZxxl Owned by:
Priority: high Milestone: 7.8.1
Component: Build System Version: 7.4.2
Keywords: Cc: pho@…, mail@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Other Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


I just compiled GHC from git.

I am amazed that one needs to download extra 200 MiB of tarballs and 100 MiB of libraries to compile GHC. The tarballs directory essentially only includes a Perl and a MinGW binary. Is this really needed for anything if not building under environments like Windows where getting that might be difficult?

It would certainly be nice to rethink the building system as to shrink the number of additional MiB's one needs to download to make the compiler work.

Change History (7)

comment:1 Changed 5 years ago by simonmar

difficulty: Unknown

We do have a new 84MB mingw64 tarball, which means that the ghc-tarballs repo is now about 130MB. That's unfortunate. It might have been better to make a new repo for this, so that only Win64 builds have to get it. What are we going to do for the source distribution?

What is the "100MiB of libraries" referred to in the ticket?

comment:2 Changed 4 years ago by igloo

Milestone: 7.8.1
Priority: normalhigh

We should make a decision about this and close the ticket, so I'll mark it high so that we don't just let it languish.

The two options are:

  • Bundle everything in one, as we do now. Makes it convenient for users, but downloads are large and it uses more disk space.
  • Have 2 (or more) separate tarballs, and require the user unpacks the right ones for their platform. Possibly confusing for people trying to build GHC.

comment:3 Changed 4 years ago by simonmar

I vote for two source tarballs. Furthermore, I vote for putting the mingw64 tarball in a separate repo, that you only have to get on Windows (sync-all can manage to do this, I'm sure), and re-make the ghc-tarballs repo so that it doesn't include the mingw64 tarball in the history. We already have logic in sync-all to check for old repo versions, so that shouldn't cause any problems.

comment:4 Changed 4 years ago by PHO

Cc: pho@… added

comment:5 Changed 4 years ago by nomeata

Cc: mail@… added

I was just made aware of the tarballs with binary code in the “source” tarball. Theoretically, for Debian either the source of that code needs to be included as well, or the binaries removed. As we use none of the data in ghc-tarballs, we’d greatly appreciate a second tarball that contains just the GHC sources, and no third-party modules.

comment:6 Changed 4 years ago by igloo

Resolution: fixed
Status: newclosed

The Windows tarballs are now in a separate repository, and end up in a separate tarball.

comment:7 Changed 4 years ago by nomeata

The Windows tarballs are now in a separate repository, and end up in a separate tarball.

Thanks, very much appreciated!

Note: See TracTickets for help on using tickets.