svn commit: r415078 - in head: . Mk

[Alexey Dokuchaev]

On Sat, May 21, 2016 at 02:25:22PM +0200, 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.

Even if we can agree on REP_TIMESTAMP variable, why `make makesum' cannot
sed -i the Makefile?

> 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.

Unless distinfo changes, svn's "Last Changed Date" won't be bumped.  The
mtimes are only required for unversioned (exported) trees, and if exported
correctly, they also do not gratuitously change.

> 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.

Don't get me wrong, I have nothing against reproducible builds idea.

> 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,

I understand that the problem with this approach is that mtime(Makefile)
changes too often, correct?  (Including the exported tree.)

> from the distinfo files, from the distfiles etc.

And what was/were the problem(s) in these cases?

> 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).

That's actually what I was trying to do, but so far the only reply I got
from Ed that we have to support svn/git/hg-exported tarballs, and per what
I see they all set files' mtimes as needed.  (If working against versioned
tree there is no problem in the first place -- AFAIR we already have some
support in src for git hashes.)

> The ports is a very complicated place for that because upstream builds
> systems are full of hidden dragons.

That's true, but so far this TIMESTAMP thing has nothing to do with how
upstream builds their stuff.  How is this relevant?

> 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.

I understand that, I just don't see why it has to be in the distinfo.

./danfe