On 5/8/06, Volker A. Brandt <vab@bb-c.de> wrote:
> Julio M. Merino Vidal writes:
> > As a simple example, imagine a utility that knows how to register rc.d
> > scripts and how to register system users and groups.
> [...]
>
> Your example illustrates your point.  But the devil is in the details.
> You would basically assemble a repository of "package-add task modules".
> While this is superior to having these tasks as scripts within the
> package(s) to be installed, these "modules" will be versioned, some might
> be MD or OS-rev dependent, or whatever.  You are moving the maintenance
> of these "modules" away from the package maintainer and towards the
> package admin tools maintainer.  The maintenance load does not go
> away, however.
>
> I am not sure if this is such a good thing.  I guess everything is
> easier if install scripts are left in the package where the maintainer
> of the actual software to be packaged has everything under control
> and can optimize and tune things.

This already happens.  All the code to manage common stuff (users,
shells, etc.) is kept in a central place (mk/install).  The difference
could be that binary packages could not be replicating it over and
over again, so you could audit once and be done with it.

Of course, install scripts cannot be nuked completely.  There are
situations in which scheme is insufficient and packages will need to
provide their own code.  But in those cases, you'll hopefully have to
audit a minimum amount of code run during pkg_add.

Cheers,

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