Subject: Re: DEINSTALL scripts for daemon packages
To: Johnny C. Lam <lamj@stat.cmu.edu>
From: David Brownlee <abs@netbsd.org>
List: tech-pkg
Date: 05/24/2001 16:40:49
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 --