Date: Sat, 21 May 2016 14:33:09 +0200 From: John Marino <freebsd.contact@marino.st> To: Baptiste Daroussin <bapt@freebsd.org>, Alexey Dokuchaev <danfe@FreeBSD.org> Cc: marino@freebsd.org, Ed Maste <emaste@freebsd.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r415078 - in head: . Mk Message-ID: <70938d6b-0fab-91b9-28b0-9dd05302a503@marino.st> In-Reply-To: <20160521122522.GJ21899@ivaldir.etoilebsd.net> References: <201605121820.u4CIKROJ004026@repo.freebsd.org> <20160513160151.GA30219@FreeBSD.org> <20160513182837.GF49383@ivaldir.etoilebsd.net> <20160513201919.GA48945@FreeBSD.org> <CAPyFy2A9L1cCikOrgBAWUo0GTCLJ4EgzqukhobaJp%2BZqv7_SpQ@mail.gmail.com> <20160519122306.GA24015@FreeBSD.org> <20160521112728.GA624@FreeBSD.org> <364d3d9f-63ff-18c8-c730-a11c57dc0673@marino.st> <20160521114358.GC624@FreeBSD.org> <20160521122522.GJ21899@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70938d6b-0fab-91b9-28b0-9dd05302a503>