Removing build metadata, for reproducible kernel builds

NGie Cooper yaneurabeya at gmail.com
Thu Dec 3 08:07:17 UTC 2015


> On Dec 2, 2015, at 23:55, Ed Maste <emaste at freebsd.org> wrote:
> 
> On 3 December 2015 at 05:51, Warner Losh <imp at bsdimp.com> wrote:
>> 
>> I noted in the review that I don’t like the default being no.
>> 
>> I also don’t like that we’re growing lots of different knobs that need
>> to be set to get a repeatable build. Let’s have one, or barring that,
>> let’s have one that sets all the sub-knobs.
> 
> My hope is that we'll have a reproducible build by default, and that
> *no* knobs need to be set. That's what I intend with my patch. I can
> rename the knob to WITH_/WITHOUT_REPRODUCIBLE_BUILD though if that's
> generally desired. If there's a consensus to default to including the
> metadata I'm fine with setting it in make release.
> 
>> I think that host and path are more worthless than date and time
>> in many environments. Who builds it likewise. Those are all things
>> that are likely to change between builds, yet change the kernel
>> image. I’d rather see it all gone when this option is in effect.
> 
> I don't follow -- other than the build iteration number (which I
> indeed missed), it is all gone.

I personally like being able to debug when user A builds on machine X vs user B on machine Y — because it's helped me find issues with peoples’ build environments in the past where I could have ended up pulling teeth.

I think the single-knob src.conf knob approach is wrong though. Why not document how to do it with build(7) and tweak newvers.sh to do this (which drives this to begin with)? That would generalize the solution, accomplish this goal, and help $work accomplish this goal, because right now we ($work) hack newvers.sh in order to change the version information to brand the product appropriately, instead of build upon existing infrastructure, as the existing infrastructure is not flexible and documented and is very static.

Thanks,
-NGie


More information about the freebsd-arch mailing list