svn commit: r415078 - in head: . Mk

[John Marino]

On 5/21/2016 2:25 PM, Baptiste Daroussin wrote:
> On Sat, May 21, 2016 at 11:43:58AM +0000, Alexey Dokuchaev wrote:
>> On Sat, May 21, 2016 at 01:33:36PM +0200, John Marino wrote:
>>> On 5/21/2016 1:27 PM, Alexey Dokuchaev wrote:
>>>> On Thu, May 19, 2016 at 12:23:06PM +0000, Alexey Dokuchaev wrote:
>>>>> ...
>>>>> I'm still not convinced though, sorry.  Ports tree can be obtained by
>>>>> a number of means, but this new ugly TIMESTAMP thingy is added for a
>>>>> very specific usecase, and there should be no problem to require that
>>>>> for that particular usecase, exported ports tree must have its files'
>>>>> mtimes correctly set.  (If svn/git/hg are not setting right mtimes on
>>>>> export, they should be fixed.)  It looks more like quick'n'dirty hack
>>>>> rather than thoroughly thought-out solution.
>>>>
>>>> Given lack of replies, I guess I'd have to elaborate a bit on problems with
>>>> TIMESTAMP and why I'm against it.
>>>>
>>>> 1. It does not line up with distinfo format...
>>>> 2. It is not needed even if ports repo is obtained as tarball...
>>>
>>> Maybe it could/should be implemented as a makefile variable instead?
>>>
>>> e.g. REP_TIMESTAMP=
>>>
>>> Just a suggestion.  I don't disagree with you.
>>
>> While still hackish, it's a *lot* less ugly and bogus as tainting distinfo.
>> (New variable in Makefile is OK because that's what Makefiles are made of:
>> variables, targets, and recipes.  Adding TIMESTAMP to distinfo is NOT OK
>> because distinfo describes port's distfiles in a form of FOO(), BAR(), ...
>> values per each distfile.)
>>
> Implementing it as a Makefile variable would make it not automatically updated.
> Meaning more work for maintainers and more chances for mistakes to happen.
>
> As stated before using the mtime of the files will end up updating this
> timestamp too often and then defeating the goal of the reproducible build.
>
> If you have watched the differents talks about reproducible builds and the
> different links provided earlier you would understand the huge benefit of
> reproducible builds for Q/A for exp-run for example where you can quickly figure
> out the real inpact of a change in base or in ports by getting quickly the list
> of packages that have changed and analyse them, instead of relying on build
> failures and discovering later that there are runtime problems like failures or
> unexpected changes. That would also allow to discover which ports needs to be
> bumped because they do link statically (unoticed until now) to a lib that has
> received a security fix. Not stating the benefits for users using binary
> packages, the speedup on publishing packages etc.
>
> Now if you disagree with the TIMESTAMP in distinfo they please make sure to
> provide a reliable in all case solution for getting this information.
>
> The choice of using distinfo this way has been decided after actually testing
> getting informations from other places like mtime from the Makefile itself, from
> the distinfo files, from the distfiles etc. We may have missed an obvious better
> solution, if that is the case then please provide a solution and please a tested
> one, because this change does not come out of nowhere, it has been sitting for a
> wile after many many tests (I do work on reproducible builds for years). the
> ports is a very complicated place for that because upstream builds systems are
> full of hidden dragons.
>
> There are many changes that would be added to the ports tree later, but we need
> that TIMESTAMP source of information first, before getting further.
>
> As a conclusion this is the less worse solution we found it works, if one has
> a better one, please provide it, but after understanding and taking in account
> the requirements.
>

It's not clear to me if 26,000 ports need a timestamp or if it's only 
26.  Plus, it's possible that a timestamp could be automatically updated 
even if it's a makefile variable.  Finally, "make makesum" could also 
detect if timestamp needs updating.

I'm hearing that besides the "what are the real requirements here?" [1] 
question that it's the location of the information (distfile) that 
people are pushing back on.

John

[1] e.g. which ports (if not all) really need it, what is impact of not 
having it, what is impact of having a wrong timestamp, etc.  I also 
agree with those that say this was not introduced in any way, at all.