[Reproducible-builds] Minimising work needed for this build-path issue
infinity0 at debian.org
Thu Oct 27 15:51:00 UTC 2016
Daniel Kahn Gillmor:
> On Thu 2016-10-27 11:18:00 -0400, Ximin Luo wrote:
>> So, I can implement option B fairly easily, but there is one ugly fact
>> about the syntax that we should think about. The way that GCC does it,
>> it means you can't strip a prefix that itself contains the "="
>> Now this is not going to matter in all the cases that *we* want to use
>> it for. Doing a `sudo find / -name "*=*"` on my system gets me one
>> result: "songs/releases/2012 - Grimes - Visions/06 Vowels = space and
>> However, we're defining a *standard* here and if it takes off, it will
>> last for quite some time and have quite wide reach. It means that if
>> someone wants to have a folder structure like e.g.
>> C:\Documents and Settings\Betrand Russell\Proofs of 1+1 = 2\Automated Proofs\Source Code\
>> or perhaps in the future:
> note that your "convenient" use of base64 here is problematic for other
> reasons, because of the "/" character -- some "uniform" paths will be more
> layers deep than others. This isn't directly relevant to our specific
> problem, but just an observation that stuffing b64 encodings into the
> filesystem might already be problematic.
Yeah I noticed that right after I sent it. There is a "urlencoded" form of base64 which avoids that problem though, it replaces +/ with -_.
> I guess quoted-printable encodings are even more likely to have problems
> with "=" though:
> 0 dkg at alice:~$ qprint -e <<<"abcdé"
> 0 dkg at alice:~$
>> these people won't be able to use this standard. Do we care about
>> these sorts of things? Even if not, we should explicitly say "Paths
>> containing '=' are not supported" - there is no sense in trying to
>> brush this fact "underneath the carpet".
> I agree that it is actively good to explicitly state this constraint.
> The constraint already exists (for debug-prefix-map).
Well, one option is to change GCC to strip at the last '=' instead of the first '='.
The "no =" constraint then moves to newprefix instead of oldprefix. I can think of much fewer places where this would be an issue, I don't know of any software that contains a "=" in its name, and even then usually they'd have a "preferred" ASCII alternative that they could use.
Anyway, I will make this change in a separate patch and see if GCC agree with it.
More information about the Reproducible-builds