From owner-svn-ports-all@freebsd.org Sat May 21 12:33:14 2016 Return-Path: Delivered-To: svn-ports-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 98E84B44EFF; Sat, 21 May 2016 12:33:14 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from shepard.synsport.net (mail.synsport.com [208.69.230.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EDED713BA; Sat, 21 May 2016 12:33:13 +0000 (UTC) (envelope-from freebsd.contact@marino.st) Received: from [192.168.1.21] (176.red-83-34-249.dynamicip.rima-tde.net [83.34.249.176]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by shepard.synsport.net (Postfix) with ESMTP id 6A6AD43CCD; Sat, 21 May 2016 07:33:11 -0500 (CDT) Subject: Re: svn commit: r415078 - in head: . Mk To: Baptiste Daroussin , Alexey Dokuchaev References: <201605121820.u4CIKROJ004026@repo.freebsd.org> <20160513160151.GA30219@FreeBSD.org> <20160513182837.GF49383@ivaldir.etoilebsd.net> <20160513201919.GA48945@FreeBSD.org> <20160519122306.GA24015@FreeBSD.org> <20160521112728.GA624@FreeBSD.org> <364d3d9f-63ff-18c8-c730-a11c57dc0673@marino.st> <20160521114358.GC624@FreeBSD.org> <20160521122522.GJ21899@ivaldir.etoilebsd.net> Cc: marino@freebsd.org, Ed Maste , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Reply-To: marino@freebsd.org From: John Marino Message-ID: <70938d6b-0fab-91b9-28b0-9dd05302a503@marino.st> Date: Sat, 21 May 2016 14:33:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160521122522.GJ21899@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2016 12:33:14 -0000 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.