On Thu, 10 Feb 2005, Alistair Crooks wrote:

> > > But let's see what else is displayed at package build time
> >
> > I didn't mention package build time.  I'm only talking about pkg_* tool
> > usage for binary packages, which has a slightly different target audience
> > (in the case of pkg_add, at least).
>
> Oh, you hadn't made it clear that you were talking about binary
> package addition. Presumably package deletion is covered as well.

Yes.

> > Right.  Such mismatches can be a very real problem, particularly if someone
> > mistakenly installs, for example, a NetBSD-current built package on 2.0.
>
> So now OS mismatch is a valuable message, and yet commands which are
> run as root on your behalf are not?

OS mismatch is a valuable message; that is a warning directed specifically
at "me", the admin, about my decision to install the package and my
operating environment in which it is installed.

If I'm running something as root (such as pkg_add or pkg_delete), I am
accepting the consequences of commands run on my behalf.  To that end:

> So the display of commands run as root is now making it so that you
> can't view anything else?  I do find that hard to believe.

Try "pkg_delete -r perl" sometime; you might be surprised.  And try deleting
*anything* managed under pkgviews; it generates @unexec's for every single
directory in the package....

If there's some kind of arbitrarily pressing need to display the fact that
"things are running behind your back", perhaps we should take the SVR4
approach, with only a one-liner about it by default (rather than one line
per every specific command)?

    Running package @exec commands...

or similar.  Likewise, we could also have

    Running INSTALL script (phase PRE-INSTALL)...

which would give you the INSTALL/DEINSTALL audit point you want, without
spewing loads of garbage all over the screen.  (Though distilling down to
these one-liners should illustrate just how little value these notices
really have.)

Even in this case, a switch is needed to turn these messages off, because
again, they're "normal" operations of pkg_add and pkg_delete.  An OS
mismatch warning, by contrast, is not "normal".

> > If there's already support, it should be documented in the Guide,

> We're getting off on a tangent here, but they are documented - see
> pkg_add(1),

> I agree that the pkgsrc guide should have information on digital
> signatures in it, although it tends to avoid mentioning binary package
> addition, IIRC.

(...and this from one of the people who really Love the pkgsrc Guide(tm).
<wide grin>)

Generation of signatures is a package *build time* operation, and filesystem
management of signatures is out of band of pkg_add, so going to pkg_add(1)
to figure out how to do that is a bit counterintuitive.

And, of course, such signing should probably become part of a bulk build,
but that's another discussion unto itself.

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>