svn commit: r350550 - head/share/mk

[John Baldwin]

On 8/6/19 9:56 AM, Glen Barber wrote:
> On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote:
>> Author: jhb
>> Date: Sat Aug  3 01:06:17 2019
>> New Revision: 350550
>> URL: https://svnweb.freebsd.org/changeset/base/350550
>>
>> Log:
>>   Flip REPRODUCIBLE_BUILD back to off by default in head.
>>   
>>   Having the full uname output can be useful on head even with
>>   unmodified trees or trees that newvers.sh fails to recognize as
>>   modified.
>>   
>>   Reviewed by:	emaste
>>   Differential Revision:	https://reviews.freebsd.org/D20895
>>
> 
> I would like to request this commit be reverted.  While the original
> commit message to enable this knob stated the commit would be reverted
> after stable/12 branched, I have seen no public complaints about
> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see
> the benefit of disabling it by default -- why wouldn't we want
> reproducibility?).
> 
> To me, this feels like a step backwards, with no tangible benefit.
> Note, newvers.sh does properly detect a modified tree if it can find
> the VCS metadata directory (i.e., .git, .svn) -- I know this because
> I personally helped with it.
> 
> In my opinion, those that want the non-reproducible metadata included in
> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their
> src.conf.  Turning off a sane default for the benefit of what I suspect
> is likely a short list of use cases feels like a step in the wrong
> direction.

My arguments for flipping this in head (and head only) are that the data
provided in uname -a when this is disabled is useful for development, and
that in head we do tailor settings towards development (e.g. GENERIC in
head vs GENERIC in stable).

The logic to handle modified trees has an inherent assumption that I think
is false, at least for my workflow and I suspect many others.  I do builds
and tests of kernels on separate machines (VMs or bare metal) from where I
use VCS to manage sources so that a kernel crash doesn't toast my source
tree.  The trees are then shared to the build/test machines via NFS.  As
a result, the build/test machines are not always able to detect that the
tree is modified either because a subset of the checkout is exported via
NFS, or the VCS tool isn't installed on the build/test machines because
they are generally barebones systems with only a base installed.  This
does mean that flipping the knob off doesn't provide all of the same info,
but it does provide the path, and the path matters because 'kgdb -n last'
uses it, and because if you use separate directories for separate projects
(e.g. git worktrees), then the path tells you which test kernel you booted.
(It is not uncommon for me to have several test projects in flight on a
single test machine for different branches.)

In the original discussion on arch, we collectively recognized that
developer builds vs release builds were different and needed different
defaults.  The compromise reached at that time was to depend on the VCS
to detect developer builds to choose the policy.  What I have found is that
in practice for at least my workflow that doesn't actually work.  I posit
that the majority of kernels built from head are developer builds, not
releases, and that the default should cater to that.  You could also always
patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I
think would give a more accurate sense of when builds are releases or not.

However, I will yield to whatever the consensus is.

-- 
John Baldwin