Date: Sun, 24 May 2020 12:12:38 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 246623] www/caddy: Update to 2.0.0 Message-ID: <bug-246623-7788-HmApU6oZGq@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-246623-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-246623-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246623 --- Comment #7 from Basil Hendroff <basil.hendroff@gmail.com> --- (In reply to Daniel Tihanyi from comment #6) Hi Daniel, Thank you for considering the additional feedback from Dan and myself. I wo= uld also encourage you to visit and continue to monitor the Caddy forum post https://caddy.community/t/caddy-version-1-end-of-life-date/7835/11 as there= has been some new feedback from the Caddy team, and, it is likely the=20 Caddy team will use this as the vehicle for further feedback. There are two key stakeholder groups here - Representing and driving it from the FreeBSD side, at this stage, are you, Dan and me; From the Caddy side, = it is Matt Holt and his team. Where possible, we want to try and accommodate t= he interests of both groups. I'm going to try to impartially, but critically, speak to this in the points below. 1. pidfile, DAEMON, etc. Like you, I'm scratching my head wondering about the significance of some elements. Maybe there's a gap in my knowledge; maybe it's a FreeBSD complia= nce thing. If it's the latter, what bothers me is that we add in superfluous elements that appear to add no real value to running Caddy in the FreeBSD r= d.c framework. The issue that we create is that, down the track, those followin= g in our footsteps, lose sight of what's relevant and what's not. Thank you for considering my suggestion about command_args reordering. I st= ill think this is a good idea, however, based on feedback from the Caddy team, I now withdraw my comments about a 'quiet mode'.=20=20 2. The location of the Caddy binary and Caddyfile. >From a FreeBSD perspective, if you are to maintain backward compatibility w= ith the V1 package, the Caddy binary should be located in /usr/local/bin/caddy = and for the Caddyfile it is /usr/local/www/Caddyfile. From a Caddy perspective,= the preferred locations for V2 are /usr/bin/caddy and /etc/caddy/Caddyfile.=20 The way to accommodate both groups is to include configurable script parame= ters in the rc script for both the binary and Caddyfile. The tough decision for = you to make will be to decide which set of defaults to use. I think the question for you to consider in this will be 'Which stakeholder group will benefit m= ost from the defaults?'. 3. Caddy2 I can understand why Dan has raised this. Matt has some concerns with the approach though. I think what's important from a FreeBSD perspective is that both V1 and V2 continue to be available for the foreseeable future. Given t= he lack of backward compatibility, this is not an unreasonable request. Is it possible to accommodate both Dan and Matt's concerns? I don't have enough understanding of the ports framework to make any suggestions around this, b= ut I guess, ideally, caddy should default to the latest version, but V1 should be selectable via some switch. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-246623-7788-HmApU6oZGq>