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 [1]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
[1] 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.
Attachment:
pgp07pQvKtgxL.pgp
Description: PGP signature