Request for stable, automated build process

Ian Darwin ian at darwinsys.com
Mon May 5 23:55:43 CEST 2008


I did mention when I jumped in that I was talking about a slightly 
different problem than what you seem to be trying to solve. That said...

> Storing your MD5s will let you know *if* you are repeating a build.  It 
> will not (reasonably) let you repeat a build.

You completely misunderstood what I said. Storing the file name, URL 
*and* its MD5 lets you be sure you are able to reproduce the build. And 
it's the only way you can (well, we actually use SHA's and RMD's in 
addition to MD5's).

It does not guarantee to build *exactly* the same binary, but you can 
*never ever* make that guarantee in general because of changes to shared 
libraries (in the Java world you have a greater chance, but even then,
even the smallest point upgrade to the JDK could in theory change the 
generated .class files), so there is really no point whatever using 
MD5's on generated binaries. None. I have no idea why Hudson bothers, if 
that's what it's using them for.

> You need some way of identifying the file you want to build *to the 
> revision control system* (so you can download that version) if you want 
> repeatable builds.

In the case I'm talking about - where there are about 5,000 different 
external programs from about 2,500 different sources - you don't even 
think about going to the revision control system (6 or 8 different 
services over 2,000 different hosts). You can ONLY think in terms of
ftp/http download of version-numbered tarballs. Period.

> MD5s sound nice to verify, if you don't trust your revision control 
> system (or perhaps the admins ;-)

See above for why revision control is completely irrelevant to us.




More information about the community mailing list