[rb-general] GNU coding standards discussion

[Ximin Luo]

Ian Jackson:
> [..]
> 
> gnu-proc-disc is not a public list, and it contains a number of quite
> difficult-to-talk-to people :-), so you may find it easier to use me
> as a go-between.
> 

Thanks for taking on this role!

>   Given the same inputs, running the build/install (normally
>   "./configure; make; make install-strip") will always install an
>   identical set of files into $DESTDIR/$prefix.
> 
>   Inputs means source code, dependencies, and tools.
> 
>   Identical means the files and directories have identical names,
>   filetypes, contents, and permissions.  (For directories, the
>   g+s permission bit may vary.)
> 
>   For filenames and contents `identical' means an identical sequence
>   of bytes.  So it does not mean only semantically equivalent
>   contents, such as an equivalent but different sequence of unicode
>   codepoints.  (If the build/install is done in a non-UTF-8 locale,
>   filenames and contents may depend on the locale.)
> 

Why are they putting this in? This contradicts the definition of "input" above. If the output may "depend on the locale" then the locale is part of the definition of "input". We'd prefer not to define "input" like this...

>   Any symlinks have identical targets, and the hardlink structure (if
>   any) wll be identical.
> 
>   If the build/install is done with the same password and group
>   databases, the files will also have identical ownerships.
> 

Again, this contradicts the definition of "input" above.

>   The modification timestamp (mtime) of each file or directory is
>   either:
>    (i) In each build/install, no earlier than the start of that build;
>    (ii) Identical across all builds/installs, and no later than the
>        age of the youngest input.
>   The ctime and atime are of no concern and may vary.
> 

Again, this contradicts the definition of "input" above. Specifically, "age of the youngest input" means not only the source code, but the time of extraction of the source code, installation time of the dependencies and tools, etc etc.

I think a simpler option would be to avoid making comments about $DESTDIR and the filesystem structure, but instead to make comments about the tarball that would be created if you did that, probably with --clamp-mtime set to the last entry of the ChangeLog - GNU packages are all supposed to have this, right?

For more theoretical discussion on what reproducibility "means" you and/or the other GNU folks might like this doc I wrote:

https://anonscm.debian.org/cgit/reproducible/buildinfo-spec.git/tree/notes/buildinfo.rst#n64

from line 64 onwards. I never "finished" it so the writing might be untidy in parts, but the major conceptual points are in there.

These abstract ideas are what has driven the latest round of concrete ideas regarding .buildinfo and the archive, and enough people here also have read them that I think they're quite watertight by now.

X

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