[Reproducible-builds] Minimising work needed for this build-path issue
infinity0 at debian.org
Tue Nov 1 13:52: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.
Updated patches here:
Everyone please feel free to comment / review before I soon send them off to GCC.
More information about the Reproducible-builds