From owner-freebsd-ports@FreeBSD.ORG Mon Oct 31 06:28:45 2011 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id B0B0E1065670 for ; Mon, 31 Oct 2011 06:28:45 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 07F4914DA62; Mon, 31 Oct 2011 06:28:43 +0000 (UTC) Message-ID: <4EAE401B.2040704@FreeBSD.org> Date: Sun, 30 Oct 2011 23:28:43 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ed Schouten , ports@FreeBSD.org References: <20111027091500.GM63910@hoeg.nl> <20111027162715.GB1012@sysmon.tcworks.net> In-Reply-To: <20111027162715.GB1012@sysmon.tcworks.net> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: ports/162049: The Ports tree lacks a framework to restart services X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 06:28:45 -0000 On 10/27/2011 09:27, Scott Lambert wrote: > On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote: >> Hi folks, >> >> As crees@ suggested, I'm sending an email to ports@ about this. >> >> What really bothers me when I use the FreeBSD Ports tree on one of my >> systems, is that the behaviour of dealing with services is quite >> inconsistent. >> >> My question is whether anyone has ever attempted to improve the >> integration with rc-scripts? In the PR I propose something along these >> lines: >> >> We know exactly which ports install rc scripts (USE_RC_SUBR). >> Why not run `/usr/local/etc/rc.d/${FOO} status' and >> `/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based >> on the return value of the first, we can run >> `/usr/local/etc/rc.d/${FOO} start' after installation. > > If all of that is contingent upon a boolean knob the admin can set, > something like NO_RESTART_SERVICES, I suspect everyone could get > what they want and the bikeshed would be limitted to what the default > for that boolean should be. > > The people who don't want the services restarted automagically can > set it and, once things use the new ports framewoork properly, not > have to worry about suprises. The people who want everything to > restarted as soon as possible can set the knob the other way. > > It could help keep our less sophisticated users from continuing to > run vulerable versions of software after they think they have done > what is needed to get the patched software. The sophisticated users > would still be free to choose which foot to shoot. > > A side effect might, eventually, be to encourage ports maintainers > to analyse their ported software for incompatible config changes > so that they can programatically halt the install and output a > warning message before attempting to stop the old daemon then > upgrading while a likely un-usable config is in place. > > I see it as win, win, if there is a knob. > > I do not like either option without a knob, depending on the box > we are talking about. Speaking only for myself I hate the idea of stopping/starting services automatically. However this feature is often requested, and is something that is provided by many other package systems. If we have people who are willing to do the work I think it's worth discussing how to do it properly. I think Scott's on the right track. The way that I envision it working would be a 3-knob system. One knob to always restart the services, one to never do it; and then asking on a per-port basis, which should be the default. I can imagine portmaster detecting this option in the pre-build phase similarly to how it detects and warns about IS_INTERACTIVE now, and giving the user a menu of options for how to handle it. I'm happy to add more details if people are interested. Where this actually becomes interesting is not in the ports build/install process, which is pretty easy to deal with, but with package installs/deinstalls. I definitely think it's doable, what we probably want to do is put a knob for this in the port's Makefile, and handle the stop/start for both the port and the package with a little script that can be included in the package, and run with @exec and @unexec. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/