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

> > 	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.
>
> Why would you need to distinguish between these deinstallation failure
> errors?  The deinstallation will just fail, and the last lines printed
> should be the most informative, as would be the case here, where you
> would see:
>
> 	The foo daemon is still running!
>
> Any recursive pkg_delete (without -f) will stop at this point and will
> not have removed any files still being used on the system.
>
	Sometimes you may want to update without stopping any daemons -
	apache springs to mind. Not as the default, but some people would
	appreciate it as an option.

> > 	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.
>
> That assumes all those daemon packages have nice rc.d-style scripts
> and that people use them.  People also modify those scripts to perform
> other tasks.  Some people copy them to /etc/rc.d under a different
> name.  Nowhere in the NetBSD documentation does it claim that the
> scripts in /usr/pkg/etc/rc.d must be used.  In fact, several of the
> scripts give instructions to copy it over to /etc/rc.d.  How do you
> ensure the correct script is called?
>
	If the admin elects to give pkg_delete the option that tells
	it to run the rc.d scripts, then it should pick the ones in
	/usr/pkg/etc/rc.d.

> > 	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.
>
> Sushi can upgrade packages by removing them and adding new ones.  The
> person using sushi should just have enough of a clue to check that the
> daemon he's about to delete isn't still running.
>
	He should be able to tell sushi to do it for him, and the package
	system should provide sushi the functionality to do it.

> Let me run through a scenario as a final argument against
> auto-shutdown during pkg_delete:
>
> Suppose someone takes, oh say the /usr/pkg/etc/pgsql rc.d script, and
> places a modified copy of it in /etc/rc.d.  He's also modified the
> actions so that on "stop", some messages are logged to disk, and an
> email is sent to the man responsible since it's running a very
> critical service, and no downtime can be tolerated.  Oh wait, but he's
> also running a second postgresql daemon on another port that started
> by /etc/rc.d/pgsql.private, which is another modified pgsql script.
> Now clearly, you'd want to run the correct script to ensure that
> postgresql is stopped correctly prior to deinstallation.  But which
> one?  And how do you detect the second postgres daemon?

	Then the admin on that machine should not pick the option that
	shuts down the daemon automatically. The pick the 'just leave it
	running' option, or leave it at the default 'fail and let me do
	it by hand'.

-- 
		David/absolute		-- www.netbsd.org: No hype required --