[rb-general] GNU coding standards discussion

[Ximin Luo]

HW42:
> Ian Jackson:
>> I will try to think about what you've said and I'll write up a new
>> draft definition.  But if you would like to do so first, please go
>> ahead and I'll review it and/or edit it and/or pass it on.
> 
> I think it's a good idea to define it (to the extend reasonable) as a
> function application with clearly defined inputs and expect the same
> output for the same inputs as suggested by Ximin. 
> 
> One problem here seems to be that for GNU projects there is no clear
> output. [..]

I think one idea that can guide this sort of definition, is the idea of "transfer-equivalence". That is, if I did `make install DESTDIR=xxx` and I transferred some of its results to you (excluding things like file inode numbers etc), then for you it would be *equivalent* to having run the build yourself (but not having to expend the resources to do so).

Indeed, you can argue that reproducibility is pointless without this concept - if we can both run the same process on the same inputs, why care that the results are different? If we're worried about security, then we just both build the source from scratch. But the point is that some people can't do this, so they have to transfer the equivalent result from someone else that already did the work, and have some concrete guarantee that the result is equivalent.

This is not the typical sort of thing that source distributions need to consider, but if the GNU project wants a definition of reproducibility, then I think you need to define this first - what is the set of information from an installation that you consider appropriate to "transfer" to another host?

We could try to start with:

- relative paths under DESTDIR
- contents
- rsync -l: symlinks [1] 
- rsync -p: mode
- rsync -t: timestamps
- rsync -g -o: user/group names
- rsync -D: probably disallow devices / specials [2]
- ?rsync -H: hard links within the DESTDIR [3]
- ?rsync -A: ACLs
- ?rsync -X: extended attributes

[1] you'd need to exclude certain absolute paths like /my/src/dir, but "standard" FHS paths are OK and necessary even
[2] actually this is included in rsync -a but I don't know why
[3] probably necessary to break ones that go outside the DESTDIR

But I'm not enough of an expert on sysadmin-type issues like this, to definitively say if this is a "full list". Sounds plausible though.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git