Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

[John Baldwin]

On 9/10/18 10:55 AM, Rodney W. Grimes wrote:
>> On 9/10/18 9:51 AM, Rodney W. Grimes wrote:
>>>> The FreeBSD base system is a reproducible build[1] with a minor
>>>> exception: the build metadata (timestamps, user, hostname, etc.)
>>>> included in the kernel and loader.
>>>>
>>>> With the default, non-reproducible build the kernel ident looks like:
>>>>
>>>> FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018
>>>>    user at hostname:/path/to/freebsd/src
>>>>
>>>> and the loader ident:
>>>>
>>>> FreeBSD/amd64 EFI loader, Revision 1.1
>>>> (Mon Jan 1 10:11:12 EDT 2018 user at hostname)
>>>>
>>>> With reproducible builds enabled the kernel ident looks like:
>>>>
>>>> FreeBSD 12.0-ALPHA5  r338195
>>>>
>>>> and the loader ident:
>>>>
>>>> FreeBSD/amd64 EFI loader, Revision 1.1
>>>>
>>>> I would like to enable the REPRODUCIBLE_BUILD knob by default for the
>>>> 12.0 release, and propose we do this by adding a step to switch the
>>>> default to the list of changes[2] that re@ commits to the branch as
>>>> part of the release process.
>>>
>>> Why not just turn this on and leave it on?
>>
>> For kernels not built against a pristine tree the extra info is useful to
>> have.  For better or worse, kgdb also parses the path to try to find
>> kernel.full (used by e.g. 'kgdb -n last'), so if you remove the path it
>> won't be able to find the matching kernel using its current logic.
> 
> So this means stable/12 users would have hassles getting kgdb to work?

No, this means that if you turn this option on in HEAD and leave it always
on (as I read your mail to say), then it would be a hassle for developers
on head.  On stable branches it would be nice to keep the info if people
are building kernels that aren't stock kernels (meaning modified source
trees).  For release kernels, crashinfo should work fine though even with
the extra information stripped.

For release builds the information is not really useful, it's only ever
useful if someone is building their own kernel for some reason (and even in
some of those cases it isn't all that useful).

-- 
John Baldwin