Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Nov 2009 08:07:29 -0800
From:      Chris <>
To:        "b. f." <>
Subject:   Re: Produce identical packages for checksum comparison?
Message-ID:  <>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
b. f. wrote:
> Chris wrote:
>> I'm also thinking of building a simple checksum database to track what actually changes
>> and what my options were when I compiled it.  It would allow me to better make
>> regression decisions.  I could also be free to delete packages and know if I recompile
>> it later that it was the exact same package with the exact same options.  Very simple
>> script to do that.  Also if say there was an option when compiling ports to produce files
>> with specific time/dates it would be helpful in pinpointing which of my port branches
>> a specific file came from.
> The elusive "reproducible build".  Many people are interested in doing
> this, and it's not as easy as it seems.  Even if you edited your
> filesystem or archives to change the timestamps of package files, the
I think that could be accomplished though the port makefiles.
> toolchain used to create the binary files in packages often injects
> random seeds, timestamps, file paths, uid/gid information, etc. that
I can understand file paths with debug info.  Timestamps?  Ok sure for a
timestamp file being generated during a make that auto increments version
numbers.  What would change about uid/gid?  I can't imagine why that
might be in the binaries.  As far as tar a simple utility could capture all
the owner and group info into a text file as strings and set files to 
values for uid/gid.  A hack for the fact that packages are using tar files.
Why would the build tools be injecting random numbers into binaries?
I'll look into it.

> creates differences from one build to the next.  You may have to hack
> several base system utilities, and then directly compare the checksums
> of binaries in archives after unpacking, or use a more intelligent
> comparison. See, for instance, one Japanese developer's attempt to do
> this in NetBSD in order to create better quality control for a
> commercial product:
> Your description of your system's problems sounds bad.  I think you
> should concentrate on fixing those first.
What can I say?  I multitask.  If I concentrated on one problem at a 
time I would
never get anything done.   For my systems problem I think I'm going to 
have to
either abandon jails or maybe try nfs instead of nullfs.  Otherwise I'll 
have to
learn the kernel code and how to debug the Freebsd kernel.

Thanks for the confirmation that I'm not the only one to think about it and
the link.  Enjoy the day.


Want to link to this message? Use this URL: <>