In article <20060622012400.GA895@britannica.bec.de> joerg@britannica.bec.de wrote:
: 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.

  Let me say right off that I don't think these two problems are
closely related.  In fact, they are quite different: the first is
about alternate dependencies, the second about steps that need to be
taken at install/deinstall time to register/unregister one package
with another, where neither is a dependency of the other.

: 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 does not *need* a web server though, so requiring one via
dependencies is wrong.  Also, it will need to be set up (manually?) to
work with the web server, right?  If glue files are needed, maybe they
can be provided by a separate package.

: 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.

  They need to install (or symlink) into different directories for
each browser.  Do you suggest to solve this via triggers?

  Or do you mean at build time, for providing the header files?

  The depency chosen at build time may affect which packages are
acceptable as dependency at run time (e. g. if the dependencies are
API compatible, but not ABI compatible).


: 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.

  I like the idea of triggers, but I don't like the proposed syntax.
I think the PLIST is the wrong place for this information.  Also, I
would very much like to get rid of multi-line entries (or entries that
refer to the next/previous entry) in the PLIST.

: This does not solve the problem how to determine whhich package to
: install to fullfil the trigger requirement.

  I don't think triggers should add dependencies: It makes perfect
sense to install a TTF font without any package that uses it (e. g. if
I use it outside pkgsrc).  Also, it make perfect sense to install
ghostscript without additional TTF fonts.

  When a package is installed that calls a trigger (like package with
a TTF font), all installed packages that are interested in this
trigger are called.

  When a package that is interested in a trigger is installed, it is
called with each installed package that calls this trigger.

  This way, the order in which packages are installed does not matter,
and all triggers are called.  This is important: say I install
ghostscript and a couple of TTF fonts.  Then later, I install GNOME
print; I expect my installed TTF fonts to be registered with GNOME
print.  If I later install another TTF font, I expect it to be
registered with both ghostscript and GNOME print.

: 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.

  I agree.  The current practice of chosing what is installed causes a
lot of problems and leads to inconsistencies.


						yours,
						dillo