svn commit: r415078 - in head: . Mk

[Baptiste Daroussin]

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.

Best regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-ports-head/attachments/20160521/d96e891c/attachment.sig>