On 11/8/05, Lubomir Sedlacik <salo@xtrmntr.org> wrote:
> On Mon, Nov 07, 2005 at 10:25:36PM +0000, Alistair Crooks wrote:
> > I think the goal is correct, but my reasons are different to Johnny's.
> > Mainly, I'd like to have a "packing list" that is exactly that - a
> > list of files and directories.  No extra @exec or @unexec statements,
> > which belong in the +INSTALL scripts.  This is for no other reason
> > that aesthetics.  Aesthetics, and a need for the tools to lose some
> > bloat in the pkg_add front, to get rid of the possibility of running
> > something horrible unknowingly as root at installation or
> > de-installation time, a separation of the +INSTALL work to the script
> > and not the pkg_install tools.
>
> i am not sure i follow the logic.  vast majority of @exec and @unexec
> calls are just simple mkdirs or rmdirs, as opposed to INSTALL scripts
> which contain things like adding/removing users, editing /etc/shells and
> such.  and you still fear of "running something horrible unknowingly as
> root at installation or de-installation time" within @exec and @unexec?
>
> otoh, i agree that "packing list" should be just "packing list" and
> nothing more.  i also think that user installation should not be
> embedded in the packages themselves, they should just merely inform
> pkg_install that they require such and such users to be present and be
> done with it.  i think that our pkg tools are showing their age pretty
> badly, their design lacks the features we need today and we are
> offloading the tasks to INSTALL scripts and pkgsrc infrastructure --
> the wrong place for them.

Indeed.

I once heard of an idea that seemed very nice to me.  Make the install
scripts declarative rather than letting them execute any code (as some of
you have said).  E.g., they'd only specify "I need this user" and the tool
could do whatever is needed to accomplish it.

Of course, this can't be complete because packages may need to do
extra things not planned beforehand by the install tools.  In this case,
we'd let them execute random commands from the INSTALL scripts, but
the admin could be warned before that (as happens now with the @exec
lines).  This could be viable because the amount of commands to be run
as root could be kept low.

How to do this?  Maybe we could have a predefined directory within
LOCALBASE containing a set of scripts (one for each action that we want
to issue).  For example, one could be 'user.sh', and receive a set of
arguments to do (de)configuration of users.  Packages could simply be
allowed to call scripts within that directory (doing things in a very simpl=
e
form, such as 'user [action] [parameters]').

I'd like to see something like this because it could allow some packages
to extend the default actions.  GConf2 comes to mind, as it could install
a common script to register and unregister schemas.  (Several other
packages could benefit from this.)

--
Julio M. Merino Vidal <jmmv84@gmail.com>
The Julipedia - http://julipedia.blogspot.com/
The NetBSD Project - http://www.NetBSD.org/