Removing build metadata, for reproducible kernel builds

[Ian Lepore]

On Thu, 2015-12-03 at 15:35 -0600, Justin Hibbits wrote:
> On Thu, Dec 3, 2015 at 3:15 PM, Ian Lepore <ian at freebsd.org> wrote:
> > On Thu, 2015-12-03 at 12:53 -0700, Warner Losh wrote:
> > > On Thu, Dec 3, 2015 at 12:55 AM, 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 this an unwise decision in the current form suggested.
> > > The kernel
> > > metadata has saved my butt enough times I really don't want to
> > > see it
> > > go by default. But see below for a reasonable (imho) middle
> > > ground that
> > > would be a good default.
> > > 
> > 
> > I'm curious why anyone wants this enabled by default, like... are
> > we
> > missing something?  Does it improve freebsd-update behavior maybe?
> > 
> > If it's just for some general "reproducibility is good" philosophy
> > then
> > I would counter with "information is even better, so don't throw it
> > away without a good reason."
> > 
> > Reproducibility is good for some people, and completely useless for
> > others, and the people who need it aren't going to mind turning on
> > a
> > knob or two to get what they want.
> > 
> > > 
> > > > > 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.
> > > > 
> > > 
> > > Yea I was reading things backwards.
> > > 
> > > In the review, I suggested that if you've modified the tree
> > > (which the SCM
> > > will tell you), then do the old format to preserve useful
> > > metadata that's
> > > really really needed and if not to use the shorter version. When
> > > you've
> > > modified the tree, reproducible builds aren't a concern at all.
> > > 
> > 
> > How are you going to determine what consitutes a modified tree? 
> >  What
> > you think of as modifications may be what I call my baseline
> > version.
> > 
> > -- Ian
> 
> svnversion resulting in a 'nnnnnnM'?
> 
> - Justin
> 

svnversion isn't going to be able to return anything useful inside one
of my build sandboxes in which there is no hint of svn anything.

-- Ian