svn commit: r458000 - head/www/nginx

[Sergey A. Osokin]

Hello,

is there any update?

Thanks.

-- 
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 <osa at FreeBSD.org> 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
>