Hi all,
on pkgrsccon we had a heated debatte about two related problems in the
current framework. I want to illustrate this problems first and propose
a solution for the new pkg_install framework. Please share your ideas
with me.

The first problem is about packages which need a certain feature from
other packages, but don't care about the concrete implementation. For
example, mail/mailman is a lot less useful, when no web server with CGI
support is installed. It also pretty much needs a MTA to hook into.
Another example is given by the family of browser plugins. They don't
really care whether it is Firefox, Opera or even Netscape 4.7, as long
as the interface version is provided.

The second problem is most prominently shown by TrueType fonts. When a
new TTF font is installed, it has to be registrated. Fontconfig, Xorg,
GhostScript, GNOME print and maybe even other packages keep individual
databases. Another example are SGML/XML stylesheets, info pages, TeX
packages etc. pp.

As a solution I propose to introduce "trigger". A package can register 
trigger programs with the framework. They get executed whenever a
package using this trigger is installed, removed or updated. Multiple
packages can provide the same trigger (Ghostscript and Xorg are both
interested in TTF fonts).

A package can tag the PLIST to invoce the trigger for a specific file,
e.g. like:
	@trigger TTF
	lib/X11/fonts/X11/geni102.ttf
	@trigger TTF
	lib/X11/fonts/X11/genr102.ttf
would result in the TTF trigger being called with both files as
arguments. In addition, it should be possible to call trigger with pure
meta data (useful for sysutils/user*). A package can also require a
trigger to be provided at least once. This allows (in combination with
the alternative framework) to handle the first problem.

This does not solve the problem how to determine whhich package to
install to fullfil the trigger requirement. Ultimately it is an
administrative decision and requires user intervention. We should keep a
list of triggers in use and provide a default choice. This could be done
similiar to mk/defaults/mk.conf and overrideable for pkg_install.
Depending on the situation the modus operandi can be one of:
(a) always select the default choice
(b) ask the user to select from the available options (e.g. from all
binary packages)
(c) bail out with an explicit error.

In Debian, either (a) [apt-get] or (b) [dselect, aptitude] is normally
used, so it makes sense to leave this as frontend issue.

Joerg