Andrew Pimlott wrote: > On Fri, Jan 24, 2003 at 03:55:55PM -0500, Bob Hilliard wrote: > > Is a libexec dir any kind of a standard? My upstream has > > configured dictd to look for user-compiled plugins in > > /usr/local/libexec, and I have never heard of such a libexec > > directory. > > You can find it the GNU coding standards, though it existed before > then. It's not in the LSB/FHS. Probably, you should use > /usr/local/lib or possibly /usr/local/share instead. 'share' for compiled plugins? That does not sound right. * I thought the share hierarchy is for all read-only architecture independent data files. * I thought 'share' was defined to be truly optional, in that it *could* be removed and nothing on the system would break by doing that. All of which leads me to believe that plugins could never reside in a 'share' directory. [Half sleepy post, take with care.] The GNU coding standards say: libexecdir The directory for installing executable programs to be run by other programs rather than by users. This directory should normally be `/usr/local/libexec', but write it as `$(exec_prefix)/libexec'. (If you are using Autoconf, write it as `@libexecdir@'.) Therefore most GNU configure autotools based programs will by default install in /usr/local/libexec for anything that uses $(exec_prefix)/libexec in the Makefile which is where your upstream will automatically look for those plugins. Would plugins normally go in libexec? I normally think of plugins as being shared libraries. Are they shared libs in this case or are they standalone programs? Perhaps the distinction is not critical. Most important is that both the producer and the consumer of plugins should agree on the same directory to be used for plugins. I am not familiar with the dictd package but would a user compiling a local plugin and running a typical default installation of a typical plugin end up with the plugin installed in /usr/local/libexec? Guessing yes. In which case I personally would leave that as the path to look for user compiled plugins. Otherwise you will be requiring users to do something special without a overwhelmingly compelling reason, which violates the principle of "it should just work". That is for the /usr/local which is defined to be driven by the local policy which would override Debian policy. Local policy in practice has often meant /usr/local has been a defacto location where GNU standards apply since it is usually 'make install' using autotools that places files there. Actually it is chaos and anarchy since many overlapping and conflicting policies have applied there. But we need a place for that. /usr/local is the the Wild West of the filesystem. Meanwhile, back at the ranch in /usr land I would remap if needed any files or directories which need to be moved in order to meet the Debian standards. That has been a point of contention with upstreams in the past. But when you are corralling ten thousand packages to work together a better methodology is required than just to meet at high noon and slug it out. Therefore if there were additional plugins that you were producing for dictd and packaging for Debian those should be installed in a subdirectory under /usr/lib such as the example of /usr/lib/mozilla/plugins/* and not in /usr/libexec where the GNU standards driving the autotools would place them. This has been discussed on the autotools lists and developers are expected move and rearrange the installation location as needed in order to meet the standards of their installation. Please correct anything misinformation I may have presented. Bob  http://mail.gnu.org/archive/html/autoconf/2002-01/msg00007.html The wonderful thing about standards are that you code first and then look to see which standard you hit second.
Description: PGP signature