Date: Sat, 21 May 2016 14:41:48 +0200 From: Baptiste Daroussin <bapt@freebsd.org> To: marino@freebsd.org Cc: Alexey Dokuchaev <danfe@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: <20160521124148.GK21899@ivaldir.etoilebsd.net> In-Reply-To: <70938d6b-0fab-91b9-28b0-9dd05302a503@marino.st> References: <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> <70938d6b-0fab-91b9-28b0-9dd05302a503@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
--x+RZeZVNR8VILNfK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 21, 2016 at 02:33:09PM +0200, John Marino wrote: > 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 th= at > >>>>> for that particular usecase, exported ports tree must have its file= s' > >>>>> 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 ha= ck > >>>>> rather than thoroughly thought-out solution. > >>>> > >>>> Given lack of replies, I guess I'd have to elaborate a bit on proble= ms 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=3D > >>> > >>> Just a suggestion. I don't disagree with you. > >> > >> While still hackish, it's a *lot* less ugly and bogus as tainting dist= info. > >> (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 happ= en. > > > > 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 bui= ld. > > > > 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 quick= ly 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 b= uild > > failures and discovering later that there are runtime problems like fai= lures 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 th= at 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 sur= e to > > provide a reliable in all case solution for getting this information. > > > > The choice of using distinfo this way has been decided after actually t= esting > > getting informations from other places like mtime from the Makefile its= elf, from > > the distinfo files, from the distfiles etc. We may have missed an obvio= us 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 sitt= ing for a > > wile after many many tests (I do work on reproducible builds for years)= =2E the > > ports is a very complicated place for that because upstream builds syst= ems 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 o= ne has > > a better one, please provide it, but after understanding and taking in = account > > the requirements. > > >=20 > It's not clear to me if 26,000 ports need a timestamp or if it's only=20 > 26. Plus, it's possible that a timestamp could be automatically updated= =20 > even if it's a makefile variable. Finally, "make makesum" could also=20 > detect if timestamp needs updating. >=20 > I'm hearing that besides the "what are the real requirements here?" [1]= =20 > question that it's the location of the information (distfile) that=20 > people are pushing back on. >=20 > John >=20 > [1] e.g. which ports (if not all) really need it, what is impact of not= =20 > having it, what is impact of having a wrong timestamp, etc. I also=20 > agree with those that say this was not introduced in any way, at all. All needs it, I have provided links in previous mails that explain reproduc= ible builds and in particular the issue with timestamps A quick hint: this timestamp will be used as a timestamp for file inside ea= ch packages, (but not only) in order to be sure that the tar files itself is t= he has the same checksum if packaging the same files rebuilt laters. the timestamps are more tricky that they looks like because of how things l= ike Makefile.pl, bytecodes for python, emacs etc works and are regenerated. I really don't care about the location of the information, I care about the= fact that it is updated often enough so it does not break building and not too o= ften so we can benefit from reproducible build. Another benefit from reproducible builds is to be able to provide in the fu= tur reliable delta packages for example Once again I provided links to resources about it in previous mails Bapt --x+RZeZVNR8VILNfK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXQFeMAAoJEGOJi9zxtz5a4fQQAKHUCiNzybgX6F07UfExzT4S k8iDrmtnbXZAL8c0SEKyimanlunQ8CgSYCoaxQNwW1/W49mWATn+aTF6nwebqgXv Q6xL0tKd9LeE5+7XnPxyOcB4m6LpcW7bgT+Ly5oBy3DOddFxruBozpiVLAPyNvoT UdhbWXxErFblLD/2DOeX6HaQgCWWuxP+gLtAzMU/TjeDGPGeCv8KjCrQk4lzyQJ9 5+hzKhL/ozWt+dZwBhq+5LrjWQlgeA3oItnXZK06caA8JVcxx+JTH5y6aIImdDVg To5B8LghQZxdLwG7SuILa6c61ixQfba5pp7wryVDWxFX9lrOThr53Bw0ZmkNKXkd jRCbXvi8RcbZp3AXHbcTUajdNxO26UxQht7ql0DTSumJE3SEkYX5CChgmjo+NMkJ JUxGYnp7FPN3x0Y4lzSVkC2OD4G3f753Cqy2gE4Py7FQucbuEEsV/EY+/k9NiCxs 5K7Y8IbvJ1YttRgyNI3p3ZHAILLqtMztguch0CZxZaVKhhoXkIirzI4HLKxn2zR9 7bUTBdjvzd+mrQuDQFtnVdWCxbfkHmkIt5zjicsZHj8k8vchjFPVgzG0fQbcEnN2 ruDFE/2JZvyze2i8k+/g4M2/AubINOGjAh/Cj301hc/3XMcLTcb9XR6wD6km+qgm lmdBKzzs3soOgqrjCozA =lbIO -----END PGP SIGNATURE----- --x+RZeZVNR8VILNfK--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160521124148.GK21899>