svn commit: r350550 - head/share/mk

[John Baldwin]

On 8/7/19 1:50 PM, Rodney W. Grimes wrote:
>> Hello,
>>
>> On Tue, Aug 06, 2019 at 04:56:14PM +0000, Glen Barber wrote:
>>
>>> 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.
>>
>> Well, my use case is that I have some machines that follow 12-stable.
>>
>> I'm not a developer. But I keep an eye on things like security bulletins
>> etc and when they come out it usually gives something like 'affecting
>> 12-STABLE prior to r<number> something like that. And I can easily look
>> at uname -a to see if this or that 12-stable machine needs to be patched
>> or whatever. That is, if reproductible_build is turned off. (or
>> without_reproductible_build is turned on) 
>>
>> Or if I mail to stable@ asking for help I'll want to say *exactly* what
>> sources I've built from. And sometimes someone will say "oh that was
>> fixed after r<suchandsuch>" and so I'll grab sources after that revision 
>> if I can and fix the problem.
>>
>> But like I say I'm not a dev. I'd guess, though, that lots of non-devs 
>> use the revision info if they follow -stable, so if I'm right in thinking 
>> this, it'd be a short list of use cases but lots of affected people.
>>
>> unless there's another way to get the svn rev number?
>>
>> Why turn off this functionality by default?
>> -- 
>> J.
> 
> Actually you have a very good point here.
> Let me raise the issue, the rXXXXXX is infact reproducible, why is
> that being excluded from reproducible builds?  If I build from the
> same source at the same version I get the same rXXXXX string in
> the resulting file.  This is reproducible.
> 
> So WHY are we excluding rXXXXXX from the reproducible build?

We don't.  The svn revision is present in uname -a even for reproducible
builds.

-- 
John Baldwin