[rb-general] GNU coding standards discussion

[HW42]

Ian Jackson:
> Ximin Luo writes ("Re: [rb-general] GNU coding standards discussion"):
>> OK, I understand now. I guess this is a fundamental difference
>> between source-installation and binary-installation. I'd suggest
>> definitions something along these lines:
>> [etc.]
> 
> Thanks for your thoughts.  Much of what you say makes a lot of sense
> to me.
> 
>> That is why it may be simpler, to instead comment about (e.g.) the
>> bit-to-bit-reproducibility of the tarballs of the installation trees
> 
> I can see why this seems like a good idea.  I think it would be better
> to provide a definition which was semantically equivalent but not
> couched in terms of tarballs.
> 
>> As for the documentation locale issue, I would suggest that if the
>> user wants documentation built in a non-UTF-8 locale then they
>> should pass a flag to ./configure to set this up. But perhaps this
>> would cause too much effort.
> 
> Surely we wouldn't want to break those users' builds (ie, have them
> produce documentation that they cannot read!).  The configure flag you
> suggest could be called --dont-do-always-utf-thing-noone-ever-wants
> (since it would only have any effect in non-UTF-8 locales).
> 
>> Anyway, this does not matter too much -
>> as long as you do enumerate exactly what you consider to be (2)
>> "user-configuration" inputs, so that binary distributions like
>> Debian know what to fix as constants.
> 
> I think that's a better approach.
> 
> 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. Instead you have in most cases a 'make install' invocation which
modifies the file tree under DESTDIR. So specifying what exactly is
considered output is more complex as "the .debs".

The approach to install into an empty directory and build a tar (with
some normalizations) might be a good idea but I see why some people wont
like this approach.

PS: I agree with Ludo's objection that a clear technical definition
    of what "reproducible" means _might_ be not worth the effort.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 854 bytes
Desc: OpenPGP digital signature
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20161202/19de2b98/attachment.sig>