On Thu, 24 May 2001, Johnny C. Lam wrote:

> David Brownlee <abs@netbsd.org> 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		-- www.netbsd.org: No hype required --