From owner-svn-ports-head@freebsd.org Tue Jan 9 18:03:46 2018 Return-Path: Delivered-To: svn-ports-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19055E6789E; Tue, 9 Jan 2018 18:03:46 +0000 (UTC) (envelope-from adamw@adamw.org) Received: from apnoea.adamw.org (apnoea.adamw.org [104.225.5.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "apnoea.adamw.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA19668B44; Tue, 9 Jan 2018 18:03:44 +0000 (UTC) (envelope-from adamw@adamw.org) Received: by apnoea.adamw.org (OpenSMTPD) with ESMTPSA id d61f579c TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Tue, 9 Jan 2018 11:03:37 -0700 (MST) Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: svn commit: r458000 - head/www/nginx From: Adam Weinberger In-Reply-To: <20180109123546.GA9882@FreeBSD.org> Date: Tue, 9 Jan 2018 11:03:35 -0700 Cc: Mathieu Arnold , v@fatpipi.com, Jochen Neumeister , ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <825D5BD5-38D0-4F96-AEEE-2FA483F9D2BC@adamw.org> References: <201801031933.w03JXLGa033758@repo.freebsd.org> <20180106134130.GA39725@FreeBSD.org> <20180106182537.GA78102@FreeBSD.org> <20180109123546.GA9882@FreeBSD.org> To: "Sergey A. Osokin" X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 18:03:46 -0000 > On 9 Jan, 2018, at 5:35, Sergey A. Osokin wrote: > > Hello, > > is there any update? > > Thanks. Hi Sergey, Sorry, but I can't give you a good answer on why the change was or wasn't discussed, and why people were or weren't notified about it in advance. It was policy long before it was written into the PHB, and that occurred in r43772, 3 years 11 months ago. At the end of the day, it's simply the only mechanism we have to ensure that users' installations match what we have in the repo. Past that I'm not really sure how to give you a satisfactory answer your question. If the policy were enacted a few months ago, I could provide insight, but we're talking about something that's been policy for 5+ years. # Adam -- Adam Weinberger adamw@adamw.org http://www.adamw.org > > -- > Sergey A. Osokin > > On Sat, Jan 06, 2018 at 06:25:37PM +0000, Sergey A. Osokin wrote: >> On Sat, Jan 06, 2018 at 08:15:16AM -0700, Adam Weinberger wrote: >>>> On 6 Jan, 2018, at 6:41, Sergey A. Osokin wrote: >>>> >>>> On Thu, Jan 04, 2018 at 08:30:55AM +0100, Mathieu Arnold wrote: >>>>> Le 04/01/2018 ?? 02:56, Vanilla Hsu a ??crit : >>>>>> auth-digest is not default module, so you don't need to bump >>>>>> PORTREVISION. >>>>> >>>>> Yes you do. >>>>> To quote >>>>> https://www.freebsd.org/doc/en/books/porters-handbook/makefile-naming.html#makefile-portrevision >>>>> : >>>>> >>>>> PORTREVISION must be increased each time a change is made to the >>>>> port that changes the generated package in any way. That includes >>>>> changes that only affect a package built with non-default options. >>>> >>>> I've tried to find a commit in doc area to better understand who and why >>>> did this change. Another question is why this so important change >>>> hasn't been discussed and why committers and community haven't been >>>> notified >>>> about that in advance. >>> >>> Hi Sergey, >>> >>> It's been policy for a long time now, a number of years at least. It does >>> feel strange at first, but it really does benefit our users in the end. >>> The >>> reason we have to bump PORTREVISION for non-default options is the same >>> reason we have to bump PORTREVISION for default options. When something >>> changes, build scripts need to know to rebuild the package. There is >>> simply >>> no way for that to happen unless we tell them to. >>> >>> I know you're not a fan of forcing default option users to rebuild ports >>> when their setup hasn't changed, but the other side of it is that we >>> often >>> force non-default option users to rebuild when THEIR setup hasn't >>> changed. >>> It works both ways, and it's just a consequence of our build paradigm. It >>> has to happen though, every time. >> >> Hi Adam, >> >> thank you very much for so long answer with so many details, I think I >> understand your opinion in this case, however would you mind to provide >> a bit more details in this case (please review my questions)? >> >> Thanks in advance. >> >> -- >> Sergey A. Osokin