[Reproducible-builds] Minimising work needed for this build-path issue

[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 "="
> character.
>
> 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
> time.mp3".
>
> 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:
>
> /srv/net/distributed-hash-table/address/VaIWP8YIWDChR2O76yiufXBsbw5g2skB/kp9VP+qVLvydovdGw==/projects/gcc-6/

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.

I guess quoted-printable encodings are even more likely to have problems
with "=" though:

    0 dkg at alice:~$ qprint -e <<<"abcdé"
    abcd=C3=A9
    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).

And "=" in filenames have other weird consequences that people might
want to avoid, like this:

     mkdir foo=bar
     ln -s /bin/ls foo=bar/
     foo=bar/ls -la

the shell treats this as variable assignment and returns an error:

     bash: -la: command not found

while this works fine:

     ./foo=bar/ls -la


Anyway, i'm OK with saying "Building in a path that contains an '='
character is explicitly not supported"


>> One other detail: Should we specify something about trailing '/' in
>> oldprefix. This can be relevant when mapping directories.
>
> Did you have a specific example in mind? I think the current behaviour
> is fine, especially if we support the arbitrary newprefix: if you give
> it "/build/pkg/=." then you'll end up with paths like ".src/blah.c",
> but if you give it "/build/pkg/=" then the result is fine.

fwiw, i think the fact that these are raw strings is fine.  the same
rules apply for "git format --prefix" and that seems to work out OK.

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20161027/b06d6d21/attachment.sig>