Subject: Re: DEINSTALL scripts for daemon packages
To: Johnny C. Lam <>
From: David Brownlee <>
List: tech-pkg
Date: 05/24/2001 16:40:49
On Thu, 24 May 2001, Johnny C. Lam wrote:

> David Brownlee <> writes:
> >
> > 	Unless I'm missing something (always possible :) this locks us to
> > 	one of the three choices:
> > 		- ignore daemons on delete (where we are now)
> > 		- fail with warning messages
> > 		- shutdown daemons and proceed
> No, you include some code in DEINSTALL like:
> 	case DEINSTALL)
> 		# ... check to see if daemon is running ...
> 		if is_running; then
> 			echo "The ${PKGNAME} daemon is still running!"
> 			exit 2;
> 		fi
> Now if someone does 'pkg_delete foo', it'll fail if the foo daemon is
> running because the DEINSTALL script returns a nonzero error.  But if
> they run 'pkg_delete -f foo', it'll still print the warning message,
> but will force the deinstallation of the package.
	That would work, but it doesn't permit you to distinguish
	between 'daemon still running' and any other type of
	'DEINSTALL failed, you should look at this' error. I would
	find this particularly relevant when running a 'make update'
	which could be deleting a bunch of other packages prior to
	rebuild and reinstall.

> This is the kind of stuff we should _not_ be adding to the pkg_install
> sources.  I mean, how do you check that the daemon is running across
> all those differently named daemons in pkgsrc with different methods
> of starting/stopping them?  The only plausible way to achieve this
> kind of check is to do it on a package-by-package basis, which is done
> be doing the check at DEINSTALL time.
	That is the job of the rc.d scripts. If the check was performed
	by DEINSTALL then I would expect it to call those scripts.

> I really don't think we should be touching (3) in your list above: I
> don't think that pkg_delete should be doing admin-type tasks like
> turning off services for you.

	I think the default should be 2 (though I will probably always run
	with 1). Whatever the decision we should provide the functionality
	that sushi will need to upgrade packages in such a situation.

		David/absolute		-- No hype required --