On 5/7/06, joerg@britannica.bec.de <joerg@britannica.bec.de> wrote:
> Hi all,

Hi Joerg,

> attached is the proposal for the SoC rewrite proposal. I'll soon add a
> follow up with more detailed information as discussed during pkgsrcCon.

I assume you have sent this to the SoC web site, right?

Now... I'd like to briefly expose an idea I've had (well... it was
possibly mentioned in the past by somebody else).  This idea could
certainly be implemented as a standalone utility, but it may make
sense to integrate (part of) it within the basic package tools.

The idea is to:
1) Have a way to avoid most of the install scripts by having a
declarative configuration file for each package.
2) Be able to easily configure the behavior of these pre/post install
tasks from an administrator's POV.
3) Allow for -- possible interactive -- package configuration after
install, similar to debconf.

As a simple example, imagine a utility that knows how to register rc.d
scripts and how to register system users and groups.  A package
providing a service, such as dbus, could say "Hey, I need a messagebus
user and I provide the dbus.sh rc.d script".  The utility could then:
notify the user about the required changes (and do not do anything);
automatically install the files in place, starting the service
afterward; interactively ask the user what to do.  I see that this
automation could be very useful for desktop installations -- and why
not, for some servers.

As said above, one of the goals of this idea is to avoid running
untrusted code from install scripts (because the code could be in the
tool itself).  Therefore, it seems to me that the new pkg_install
tools should have some kind of integration to either do all these
tasks themselves or directly call an external utility (say,
pkg_setup).  I mean, the package should not explicitly execute
pkg_setup, because this could mean including a post-install script.

This utility should be extensible so that e.g., installing gconf2
provides a module for it that lets packages providing schemas to
register them in the database following the same ideas as above.=20
Basic functionality could include: handling rc.d services, users,
groups, inet.d services, rpc entries, pam.d modules...

Of course this goes beyond the original idea of the pkg_install
rewrite project and is possible big enough to be a project of its own.
 I just wanted to expose this in case that it needs to be taken into
account in this rewrite.  Or why not, to gather comments about the
idea ;-)

Thanks,

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