Re: Dselect / dpkg interaction.
Kenny MacDonald writes ("Dselect / dpkg interaction."):
> After talking to Stephen Tweedie <email@example.com> last night about
> my understansing of the current way which dselect and dpkg handle the
> 'Z' conffiles option, he came up with one possible solution I thought
> should be aired.
> At the moment, dselect sets an environment variable, and dpkg then
> tests this and spawns a new shell if appropriate. Is that correct?
> Stephen suggests that dselect should trap the SIGSTOP from dpkg, and
> not treat it as a SIGTERM. dselect should then send itself a SIGSTOP,
> followed by a SIGCONT. This means the signals are propogated back to
> the originating shell, altogether cleaner and less resource hungry.
I think Stephen is trying to solve a different problem here.
What the problem was (and I hope it's fixed now) was that, when run
automatically when the user logs in as root for the first time,
dselect wasn't invoked from an interactive shell. Thus, when it got
SIGTSTP there was no shell to take over control of the terminal.
dselect doesn't set the DPKG_NO_TSTP environment variable - this has
to be set by the script that runs dselect when root logs in for the
What dpkg does, if the environment variable isn't set, is to send the
whole process group a SIGTSTP. This has approximately the same effect
as if the user typed ^Z - it suspends both dpkg and dselect (and any
script that might have invoked them), and when the shell notices this
it gives a prompt to the user. When you say `fg' it sends both dpkg
and dselect a SIGCONT, and things resume where they left off.