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
neutral
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:
http://mail-index.netbsd.org/tech-toolchain/2009/02/17/msg000577.html
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.
Chris
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
