GHC repos etc

Manuel M T Chakravarty chak at cse.unsw.edu.au
Thu Oct 22 19:58:51 EDT 2009


Simon Peyton-Jones:
> As Simon says below, we've decided to back out the new wget  
> mechanism for tarballs.

I am very glad to hear this.

> a) Make a new darcs repo solely for the Windows Mingw blob.
> b) This is gotten by darcs-all in the same way as any other library
> c) Obliterate the Mingw-blob patches from the GHC repo
>
> Concerning (b) you may wonder whether you need to get this blob if  
> you are on Unix. Well no.  But 'darcs-all get' already gets the  
> unnecessary Win32 libs on Unix, and the unnecessary Unix libs on  
> Windows.  We could fix that, by making darcs-all a bit more  
> selective, and Ian will think about that.  (When building source  
> *distributions* we want both, because we have just one source  
> distribution for every platform.)

To be honest, I don't mind if it gets the windows-related repos on  
unix.  Sure, it'll make darcs-all pull a bit slower (but it is so slow  
from AU anyway, that I always go and do something else in the  
meantime, so it doesn't matter to me) and it'll take a bit of disk  
space, but disk space is sooooo cheap these days that I don't think we  
need to burn cycles on saving a little.

IMHO the overriding design criterion for all these repository-related  
matters is simplicity.  The simpler the setup, the less likely it is  
to break.

> | Also, since we now have at least 12% of our repo taken up by two  
> huge
> | binary patches, I suggest we take the unprecedented step of  
> obliterating
> | those patches from the master repo.  Unfortunately we also have to
> | obliterate 8 dependencies.  We could have darcs-all check for the
> | presence of the obliterated patches and suggest unpulling them.
>
> Ian will make darcs-all do this check; and will emit very clear  
> guidance about the 'unpull' commands you have to execute.  So the  
> effect should be:
> 	- Doing the unpull is easy
> 	- If you forget, you'll get a reminder
> And as a result the GHC repo will be noticeably smaller.

As I already said, I am not worried about disk space (especially space  
taken by clean repo, given how much bigger a repo gets when building).

I assume that the patches that you want to obliterate are *after* the  
last tag/checkpoint.  Otherwise, I can't see how this plan is going to  
work.

And thanks for quickly sorting out the issue with wget!

Manuel



More information about the Cvs-ghc mailing list