Dynamic plugin modules and OS packages

[Nicolas Williams]

On Tue, Jul 13, 2010 at 01:46:55PM -0700, Russ Allbery wrote:
> ghudson at MIT.EDU writes:
> 
> >   * We add "include" support to the profile library, and the OS adds
> >     "include /etc/krb5.conf.d/*" to its standard krb5.conf.  Each
> >     plugin package supplies a profile fragment giving the location of
> >     the dynamic object and an enable/disable boolean (which may
> >     default to on or off depending on the packaging model and/or the
> >     plugin).
> 
> I prefer this approach.  I've been wanting this for a long time for other
> reasons.

+1

Discovering plugins by shared object presence in a directory is
undesirable: it means you cannot disable a plugin without uninstalling
it, and you end up hoping that the plugins are packaged separately from
other functionality so that you can install/uninstall just the plugin.

Packaging is not a good enough hammer for this problem.

But discovering configuration by reading config file snippets from a
files in a ".d" directory is highly desirable as it means that there's
no need to script the editing of a single config file (which can be a
pain), and that there's no need to write a program to administer plugin
configuration (which to can be a pain).

Note that one might nonetheless use packaging to distribute these config
files.

Nico
--