Date: Sat, 21 May 2016 13:35:08 -0600 From: Ian Lepore <ian@freebsd.org> To: Alexey Dokuchaev <danfe@FreeBSD.org> Cc: Baptiste Daroussin <bapt@freebsd.org>, 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: <1463859308.1180.383.camel@freebsd.org> In-Reply-To: <20160521182211.GA96389@FreeBSD.org> References: <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> <20160521124148.GK21899@ivaldir.etoilebsd.net> <20160521163832.GB97771@FreeBSD.org> <1463850648.1180.374.camel@freebsd.org> <20160521182211.GA96389@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2016-05-21 at 18:22 +0000, Alexey Dokuchaev wrote: > On Sat, May 21, 2016 at 11:10:48AM -0600, Ian Lepore wrote: > > This is just crazy-talk. In what way is an update timestamp NOT > > "info" > > about the distribution files? The file isn't named distchecksum or > > In a way I've outlined earlier: distinfo is a set of per-distfile > values > of certain functions. TIMESTAMP is not, it's not a function of any > of > the distfiles and it is not obvious exactly how it is related to > those > distfiles. I've explained it earlier today, you should've replied to > *that* email [1] if you object. > > > dist_sha256_only, or dist_only_what_alexey_likes_to_see. It is > > metadata, it has always been metadata, and now that there is new > > metadata necessary to achieve new functionality, the one and only > > place > > that makes sense for it to be is the existing distinfo metadata > > file. > > The difference between SIZE(), SHA256(), and TIMESTAMP is that the > first > two are required to be there for reference, something to compare > against. > TIMESTAMP is just some frozen timestamp, and could be obtained > elsewhere > without breaking the whole idea (as I see it right now). Polluting > data > with not-being-a-reference metadata is just wrong from engineering > point. > > > Saying that the info can be obtained from version control is more > > crazy > > -talk. Do we add support for every version control system that > > ever > > existed to support every user of ports other there? > > Well, first, we do officially use SVN. Second, for a versioned tree, > getting correct timestamp is just a few lines for another popular > VCS, > as we speak of versioned tree. Third, I doubt that *every* ports > user > would want to know or care for reproducible builds; most just want to > change some options and "make install clean". > > > The people most interested in the new reproducible build > > functionality > > are the ones most likely to be using some local version control > > system > > which is not svn or git (we use both cvs and mercurial for various > > generations of our ports trees at $work). > > Yet when I asked why it can't be fetched from the VCS, I was told > that > we care about unversioned tarballs, and that's the problem. > > > Instead of demanding that the people actually doing useful new work > > justify this tiny insignificant detail of their implementation > > because > > it offends your view of how things should be, perhaps you could > > provide > > some argument about what harm the new value does. Something based > > on > > actual facts, not just "I think it's ugly" or "I think it's wrong." > > But I did [1]. And I'm not demanding anything, just think that > distinfo > is not the best place to put TIMESTAMP in. (And to a lesser degree, > is > that it should be possible to avoid hardcoding it anywhere, but > that's an > open debate still.) Adhering to some "harm" here looks like a straw > man > argument, sorry. > > ./danfe > > [1] http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2769892+0+current/sv > n-ports-head > So in a fairly predicable fashion, based on the way this thread has evolved, you dismiss a call for actual facts showing why an idea is bad as irrevelent and then just point again to a summary of your personal opinions and reiterate that they should rule the day. Please don't bother to CC me in any further response to this thread, it appears to be information-free, and I'm done with it. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1463859308.1180.383.camel>