Dynamic plugin modules and OS packages
Nicolas.Williams at oracle.com
Tue Jul 13 17:07:51 EDT 2010
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
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
More information about the krbdev