svn commit: r350550 - head/share/mk

[Warner Losh]

On Wed, Aug 7, 2019, 8:47 PM Rodney W. Grimes <freebsd-rwg at gndrsh.dnsmgr.net>
wrote:

> > 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.
>
> I think I know what it is that IS removed, it is the path to
> the kernel build, and the host, that is what I am missing.
> That data is rather critical to me, as it is I believe your
> objection too.
>
> Again, I think if we split this into kernel/userland we can
> have it kernel off, userland on in head and I think that
> takes care of everyones complaint about wanting it turned off
> in head, and keeps the state that has those of us wanting it
> turned on in head.
>
> Am I correct in that your main reason for wanting to have this
> off in head is to get the kernel meta data for the path to the
> kernel John?  If that is the one use case in head can we just
> turn it on for the kernel build only?
>

I think that's too much complication for too little benefit. It's a
development system, so there is little benefit to making things
reproduction... almost none. If we want to build packages for current,
those few machines can make it reproducible. It's no different than WITNESS
or malloch checking...

Warner


> John Baldwin
> --
> Rod Grimes
> rgrimes at freebsd.org
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>