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

[Ximin Luo]

Bernhard M. Wiedemann:
> On 2017-03-14 14:35, Ximin Luo wrote:
>> Basically, I don't see how the current spec (with the semi-open mapping algorithm) breaks any of the use-cases you described:
>>
>>> 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.
>> Can you describe this in more detail?
>>
> Hi X,
> 
> I have only be following the discussion on the side, so I might be
> missing some details, but IMHO there is something missing in the spec.
> That is the part about why were there paths in the output in the first
> place? Was this meant to be part of the binaries' debuginfo?
> If so, it would have to be (unambiguously) un-mapped later by another
> tool such as gdb that needs to find the original source file based on
> the mapped path
> and the un-mapping method might depend on if algorithm (1) or (2) was
> used by the compiler. So how would gdb know?
> 

Right, so in this case gdb could define their own standard that says "when consuming BUILD_PATH_PREFIX_MAP you MUST apply it using algorithm X" and try to get GCC and Clang to adopt this standard.

I allow for this in the current spec, where it says:

"Producers who build *general software* that uses this variable, MUST NOT expect
any special contracts on the output emitted by *general consumers* based on
this variable ― only that their output be reproducible when the build path
changes and the value of this variable is changed to match the new paths.

On the other hand, if you know you will only support a limited set of
consumers, you may expect that they apply these mappings in specific ways."

gdb isn't technically a producer per-se so perhaps I could tweak the wording a bit, but I think the intent is clear and there should be no misunderstanding in practise.

OTOH I don't think I should spend effort on trying to define such a debugging standard *right now*, given everything else on the task-list for R-B.

> Also, might there be cases, where upstream projects set a map variable
> value and it would only work on one of the algorithms and not on the
> other? [..]

I don't think this would be the case, and that's why I formalised the problem earlier. I'll explore it a bit more tomorrow.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git