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

[Daniel Shahaf]

Ximin Luo wrote on Tue, Mar 21, 2017 at 11:32:00 +0000:
> Ximin Luo:
> > Daniel Shahaf:
> >> Ximin Luo wrote on Wed, Mar 15, 2017 at 09:24:00 +0000:
> >>> Well, if I add too much text just to cater to minority cases or
> >>> imagined future scenarios, other people would complain that it's too
> >>> long. In the absence of a concrete suggestion I'll just leave it like
> >>> it is.
> >>
> >> I intentionally didn't offer a concrete suggestion, since I wanted us to
> >> first agree on what the bug _was_ before agreeing on how to fix it, and
> >> since there are several possible fixes and I didn't want to preëmpt the
> >> discussion by writing a patch that specifies one of them.  I'd be happy
> >> to come up with patches, if you wish, but I think that should come later.
> >>
> >> The problem in the text is simple: how can a Makefile pass a prefix-map
> >> to $(CC), without knowing what the value of $(CC) is?
> >>
> >> [..]
> >>
> >> As to an example, how about a project foo that has subdirectories 'bar'
> >> and 'bar-addons' and then adds 
> >>    ${SOURCE_ROOT_DIR}/bar=bar
> >> to prefix map.  That project would be reproducible if $(CC) chooses #1
> >> but not if $(CC) chooses #2.  That is, it'd be reproducible with clang
> >> but not with gcc.  Do you agree that it'd be better for foo to be
> >> reproducible regardless of the value of $(CC)?
> >>
> > 
> > I see what you mean, OK. Thanks for the example.
> > 
> > I would consider this a buggy producer, to only add one directory to the map but not the other one, even though one is responsible for both directories. I'll see if I can figure out a way to explain this more precisely. In the concept that I have, when a producer "acts properly", #1 and #2 would have essentially identical behaviour.
> > 
> > [..]
> 
> I tried to clarify what I mean here:
> 
> https://anonscm.debian.org/cgit/reproducible/build-path-prefix-map-spec.git/commit/?id=f1b80a834fe5c3cea5899c48a21d02cb38b260ed
> 
> Relevant part:
> 
> +Producers that expect reproducible output MUST append at least one distinct
> +mapping for each top-level directory that the build is expected to take place
> +under.
> 
> Does this address your concern?
> 

I'm afraid it does not: the new sentence does not address the
interchangeability issue (between gcc and clang), nor the composability
issue (build-depend'ing on both gcc and doxygen).

We've been discussing these issues for a while so I'd like to record
these two issues as bug reports somewhere; where's a good place?  Even
a simple ./TODO file in the master branch would be good enough, if
not a proper bug tracker.

> There is still the corner-case that with (1), x=/path/abc needs to be
> placed after y=/path/a. Not sure the most elegant way to handle that,
> but "producers SHOULD append the mappings in sorted order" would work.

Would that work even if the x=/path/abc and y=/path/a mappings were
added by different layers in the build stack?

For example, suppose the distro's build system initializes the map to
y=/path/a, and then a particular package is being built and that
package's build scripts append x=/path/abc to the map.  If the map must
be in sorted order, then the particular package would need to inject its
mapping into the middle of the variable.

> I'll see if GCC let me change their algorithm to (2), though.

Thanks Ximin.

Daniel