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

Bernhard M. Wiedemann bernhardout at lsmod.de
Tue Mar 14 20:43:43 CET 2017

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?

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? We certainly would not want to impose on them adding extra logic like
if compiling_with_gcc ; then
elif compiling_with_clang

That even requires knowledge of which consumer implements which
algorithm and there will always be an unlimited number of
yet-to-be-written consumers not covered.

hoping for enlightenment

Bernhard M.

More information about the rb-general mailing list