svn commit: r350550 - head/share/mk

[Xin LI]

On Wed, Aug 7, 2019 at 1:50 PM Rodney W. Grimes <
freebsd-rwg at gndrsh.dnsmgr.net> 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?
>

Because svnversion returns the base revision (the repository revision as of
last checkout) instead of the 'COMMITTED' revision (the last commit
revision of the working copy that was checked out), and it means for the
same set of source, there can be multiple possibilities, making it no
longer reproducible?

I haven't dig deep on this topic, but it seems that parsing 'svn info'
output would solve it (by using "Last Changed Rev:" value).

This issue do not exist on git.