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

[HW42]

Daniel Kahn Gillmor:
> On Tue 2016-10-25 08:29:00 -0400, Ximin Luo <infinity0 at debian.org> wrote:
>> Option A
>>
>> oldprefix = getenv("SOURCE_ROOT_DIR")
>> newprefix = getenv("SOURCE_ROOT_PREFIX") or "."
>>
>> Pros: Simple, easy to understand. Works almost exactly as
>> debug-prefix-map which has already existed for ages in GCC.
>> Cons: Uses two environment variables.
>>
>> Option B
>>
>> oldprefix, newprefix = getenv("SOURCE_PREFIX_MAP").split("=", 1)
>>
>> Pros: Works *exactly* as debug-prefix-map

SOURCE_PREFIX_MAP is less like to colide with existing usage than
SOURCE_ROOT_DIR.

>> Cons: Have to parse the thing. GCC splits on the first "=" but I
>> found this out by looking at the source code
>> (gcc/final.c:add_debug_prefix_map), it's not explicitly documented.
>> Someone else could split at the last "=" for example.
> 
> While i think A would be simpler in a perfect world with no history, i
> think i prefer B here.

I would prefer A because it saves consumer from parsing and makes the
spec a bit shorter/simpler but I'm fine with both.

> We'll be documenting this, so we can simply define which "=" character
> we split on.  I'd even be fine with saying that we don't allow "=" in
> either path, fwiw, if it makes things easier.
> 
> B has the advantages of being able to justify it with reference to
> known, existing functionality (debug-prefix-map) and the environment
> variable name is clearer (none of the "ROOT" ambiguity).
> 
>> Option C
>>
>> oldprefix = getenv("ALLSOURCES_DIR")
>> newprefix = "."
>>
>> Oh em gee what is going on here? Well this is a slight hack. Instead
>> of setting SOURCE_ROOT_DIR=/build/blahblah we set
>> ALLSOURCES_DIR=/build so that "blahblah" remains in the build output.
>> This is analogous to the difference between "datadir =
>> /usr/share/@PACKAGE@" vs "datarootdir = /usr/share" (in GNU
>> installation directories naming conventions).
>>
>> Pros: Simple for implementers, one environment variable that doesn't
>> have to be parsed.
>> Cons: Requires reproducers to do the build in a directory called
>> "blahblah". At least, everyone can do this - if you can't create
>> directories with arbitrary names, you probably can't set environment
>> variables either. However it does mix up two different mechanisms
>> (env var + directory naming) to achieve reproducibility.
> 
> This also makes it harder to do a reproducible build from a VCS
> checkout, fwiw, if the build path is going to have the version number in
> it.  the VCS checkout is likely to just be in $PACKAGENAME, and having
> to rename it to $PACKAGENAME-$VERSION just to do the build seems weird
> and potentially problematic.  We want it to be easy to reproduce, with
> minimal hoop-jumping.

+1

There are also other useful cases in which a choosable prefix helps.
For example when you build stuff without unique version numbers you
could use something like:

  newprefix = mypackage-$(git rev-parse --verify HEAD^{})

So I think we should keep the arbitrary choosable prefix.


One other detail: Should we specify something about trailing '/' in
oldprefix. This can be relevant when mapping directories.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 825 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20161026/85d2d01b/attachment.sig>