Date: Thu, 3 Dec 2015 00:07:14 -0800 From: NGie Cooper <yaneurabeya@gmail.com> To: Ed Maste <emaste@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Removing build metadata, for reproducible kernel builds Message-ID: <4D787F21-4607-44F0-9CA8-CB2323DD72AA@gmail.com> In-Reply-To: <CAPyFy2CZYV%2B-5pDQjCA4Btct1VZUyEQUuL2iU1z07Ff-n2Y9Hg@mail.gmail.com> References: <CAPyFy2AYeN9XNg=b0=JMWDC9ctWarfiZ-5zQorOPhguDJgxYpg@mail.gmail.com> <D9AF1C8B-431C-4359-988F-FDEEF8FAD981@bsdimp.com> <CAPyFy2CZYV%2B-5pDQjCA4Btct1VZUyEQUuL2iU1z07Ff-n2Y9Hg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Dec 2, 2015, at 23:55, Ed Maste <emaste@freebsd.org> wrote: >=20 > On 3 December 2015 at 05:51, Warner Losh <imp@bsdimp.com> wrote: >>=20 >> I noted in the review that I don=E2=80=99t like the default being no. >>=20 >> I also don=E2=80=99t like that we=E2=80=99re growing lots of = different knobs that need >> to be set to get a repeatable build. Let=E2=80=99s have one, or = barring that, >> let=E2=80=99s have one that sets all the sub-knobs. >=20 > 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. >=20 >> 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=E2=80=99d rather see it all gone when this option is in = effect. >=20 > 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 =E2=80=94 because it's helped me find issues with = peoples=E2=80=99 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D787F21-4607-44F0-9CA8-CB2323DD72AA>