Subject: Re: pkg_delete "Executing" output
To: Johnny Lam <jlam@NetBSD.org>
From: Greg A. Woods <email@example.com>
Date: 02/11/2005 18:30:27
[ On Friday, February 11, 2005 at 10:02:52 (-0500), Johnny Lam wrote: ]
> Subject: Re: pkg_delete "Executing" output
> Jeremy C. Reed wrote:
> > Would one of our pkgsrc developers would put in a malicious @exec/@unexec
> > line?
> No, but I can see accidentally putting in an @exec/@unexec line that has
> unfortunate consequences. We (pkgsrc developers) are definitely far
> from perfect.
Yeah, sure, but the same kind of mistake could be made to any of the
other scripts or script fragments that run during the installation and
Heck someone could even make this kind of mistake in the pkg_install
tools themselves, and it might not get noticed for a long time, long
after the bleeding edge adopters were already cut up pretty bad,
especially if it was something that could go unnoticed for a while.
But these kinds of mistakes are NOT EVER best found by spewing endless
transcripts out to the screen and hoping for some insanely curious
person to read (and deeply understand) them all every time.
Logging all actions non-default could be useful, but even then probably
only as a debugging tool, not a regular every-time-you-run-it audit.
The whole procedure runs as root every time, all the time. Users
installing packages _MUST_ either trust the whole package _and_ all its
install/de-install side-effects, or they MUST NOT trust it AT ALL.
Whether that trust is gained implicitly or explicitly is a whole
different issue, but the goal should be that end users installing
"trusted" binary packages shouldn't have to worry about trying to debug
mistakes that were accidentally introduced, and any early adopters of
the bleeding edge can already use other existing debugging tools
(e.g. "-v") to properly discover what's happening (or not happening) out
of the ordinary without everyone else having to suffer the barage of
what they will see just as noise to them.
> Regarding the issue of whether the user should be notified, I think
> INSTALL/DEINSTALL scripts should also tell the user when they are doing
> something that permanently affects the state of the system, e.g. adding
> new users, "rm -rf" directories, etc. Currently, I've written the
> template INSTALL/DEINSTALL scripts to output these notifications for
> exactly these cases.
Well, hmm...., yes, there's a fine line here though. "normal" expected
actions during a package (de)install shouldn't be chattered on about
unnecessarily lest the chatter detract from any really important _error_
or _warning_ messages indicating that something is not normal.
Note that chatter about "expected"/"normal" system state changes is
noise to most folks, but progress indicators are not, esp. for
procedures that could take any significant amount of time. IIRC many
human interface studies have shown 5 seconds to be about the limit a
person can be expected to wait without any progress indicator. Maybe
that time has even decreased significantly in the last decade. Even so
progress indicators should be optional (and at worst enabled by default
only when stdin, stdout, _and_ stderr are the user's interactive TTY).
In any case Some of the stuff that is now displayed in the template
+INSTALL script really should be appended to the +MESSAGE file so that
it's displayed once along with other pertinent information and so that
it's there for posterity and subsequent report generation. There's
nothing quite equivalent for +DEINSTALL, but I'm not sure there needs to
> We should sweep pkgsrc for package-specific
> INSTALL/DEINSTALL script extras that may also do these types of actions
> and cause them to notify the user of what they are doing, and add a note
> to the pkgsrc guide as well.
Yes, consistency of all (DE)INSTALL scripts with the correct best
behaviour would be a good thing.
Documentation is also a good thing! :-)
Greg A. Woods
H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Secrets of the Weird <firstname.lastname@example.org>