[rb-general] rb-prefix-map spec: don't be as democratic to consumers

Daniel Shahaf danielsh at apache.org
Sun Mar 12 16:04:09 CET 2017

Ximin Luo wrote on Fri, Mar 10, 2017 at 13:46:00 +0000:
> Daniel Shahaf:
> > [..]
> > 
> > Letting consumers choose semantics would hinder adoption by producers:
> > it would burden producers with figuring out how to set BUILD_PATH_PREFIX_MAP
> > to values that would be interpreted correctly regardless of which semantics
> > the consumer chooses.
> > 
> > [..]
> > 
> > I was thinking of a different use-case.  One use-case, the "two libxz's"
> > example, is that of an upstream project that wants to allow multiple
> > downstreams to build it reproducibly, regardless of which compiler those
> > downstreams use.  Each individual downstream would use either gcc or
> > clang, but the upstream project needs to support both.
> > 
> > [..] nor on whether $(CC) is gcc or clang [..]
> > 
> This has never been an aim of the reproducible builds project. I don't
> think we should spend effort trying to achieve it, and there are many
> many things to do on this front besides this envvar. No language
> anywhere AFAIK specifies the binary output of a given piece of source
> code.
> If you are talking about consistent standard debuginfo paths, this is
> also outside the scope of this variable, which is a way to achieve
> broad reproducibility and does not constrain the semantics of the
> actual reproducible result.

I'm not talking about standardizing debuginfo paths.  As you say, that's
out of this spec's scope.

I'm also not talking about causing different implementations of
a language to produce binary-equal source code.

Before I try for a third time to clarify myself, perhaps one of the
lurkers would like to jump in and help Ximin and me understand each

Or alternatively, Ximin if you could explain what part of my message
wasn't clear, I'd be happy to clarify it.


(Snipped rebuttals; they were good rebuttals of these two new points,
but did not address the points I was trying to make.)

More information about the rb-general mailing list