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@alice:~$ qprint -e <<<"abcdé" abcd=C3=A9 0 dkg@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
signature.asc
Description: PGP signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds