svn commit: r415078 - in head: . Mk

Sat May 21 12:41:55 UTC 2016

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 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.

All needs it, I have provided links in previous mails that explain reproducible
builds and in particular the issue with timestamps

A quick hint: this timestamp will be used as a timestamp for file inside each
packages, (but not only) in order to be sure that the tar files itself is the
has the same checksum if packaging the same files rebuilt laters.

the timestamps are more tricky that they looks like because of how things like
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 often
so we can benefit from reproducible build.

Another benefit from reproducible builds is to be able to provide in the futur
reliable delta packages for example

Once again I provided links to resources about it in previous mails

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-all/attachments/20160521/de7948be/attachment.sig>