Date: Sat, 21 May 2016 14:25:22 +0200 From: Baptiste Daroussin <bapt@freebsd.org> To: 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: <20160521122522.GJ21899@ivaldir.etoilebsd.net> In-Reply-To: <20160521114358.GC624@FreeBSD.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--BEa57a89OpeoUzGD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 problem= s 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... > >=20 > > Maybe it could/should be implemented as a makefile variable instead? > >=20 > > e.g. REP_TIMESTAMP=3D > >=20 > > Just a suggestion. I don't disagree with you. >=20 > While still hackish, it's a *lot* less ugly and bogus as tainting distinf= o. > (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.) >=20 Implementing it as a Makefile variable would make it not automatically upda= ted. 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 f= igure 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 failure= s 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 h= as 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 testi= ng 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 b= etter solution, if that is the case then please provide a solution and please a t= ested 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 h= as a better one, please provide it, but after understanding and taking in acco= unt the requirements. Best regards, Bapt --BEa57a89OpeoUzGD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXQFOxAAoJEGOJi9zxtz5aLfkP/3k/iSSgdQGeIjwUFdF91dy1 0MH4g9USbMNfeCk4RCJ/GjZ8pPY6d4OWJGsHiSfISLcOYRi6YmruHHgOa++ciBHW yxsHOc0adeZjIUmxvMhdN9+907wUNvU0YhTPiZW3e4JBMt1Jxom+t9fa9wXfvovf iZJF5SDTnlFtRPzstbkRJRKpqXAaYBt7VQecL/NMg8wUvKGrOQ+AIfr/l1nnjQMw Vj/VG24QDAlS+tCgSQQovgH8UcgQ3eItt2dGDd1mnXvslJjC9Q0zbUFGuZ/4i/OA xflW9ExyeHSmH3GjGD0aMsuHxI/f5SV04fdOgfJ2/5deG9IulKqwZVHjxRChwygD ClM/0N7aiSkNOwsETArzPUwfhgyTqbbZqMIsbiYee9Spk2FvLD3qE7VbhEz9E+4N QMTjC9fCcRql8wg1povbGt7o+bPWwjkGEuWy3lC58XO34fyDUO0uP38YXsgvKBDg 294XFifh0bfpMxo+csGtqJy62uDRVy/XAwi+tWSSZ7kB9wcoFQGJ0hJf3znGMxeV yhZyhhYezad/5Y+yNtRGUjC+iFDAqL/9AxZfsJY01SLBZ8GuuavE/kiPgltiTMLR MUMetkJs9EW4H0hlI9sYiXETYP9tVW2XazfUOHZzNC83XAOQ4M7MGDkFFD/WFrPb N7nslmPV4msCh/AQ8jVm =maAF -----END PGP SIGNATURE----- --BEa57a89OpeoUzGD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160521122522.GJ21899>