[sf-perl] poll: directory layout question

Steve Fink sphink at gmail.com
Thu Apr 22 10:09:06 PDT 2010

That question borders on a religious argument, but a safe answer is
that you have to allow it to be configured either way. Or even weirder
ways. If you don't, the packager for some distribution will spit on
you in public. (Or throw rocks at you, if you've neglected to support
DESTDIR or an equivalent.)

When building an RPM with an autoconf-ish configure script, for
example, the standard configure macro will pass in --bindir, --libdir,
--datadir, --kitchensinkdir etc. This allows it to adapt to the
standards of the distribution it is being built for.

If it's only for your own use, I think the arguments usual arguments are:

  $PREFIX/etc/..., $PREFIX/lib/..., etc.: allows some directories
(lib, bin, share, etc.) to be mounted read-only and/or hosted on a
network drive. (And if you leave out the tool/ layer, you don't have
to worry about $PATH and $LD_LIBRARY_PATH etc.) Also conforms to

  $PREFIX/tool-$VERSION/etc/...: puts everything in one place.
Especially useful if you want to have multiple versions installed
simultaneously. Also makes it easier to find the various pieces
without wandering around the filesystem.

On Thu, Apr 22, 2010 at 9:54 AM, David Alban <extasia at extasia.org> wrote:
> greetings,
> say you're developing "tool 1.0".
> say tool has some config files you want in an etc directory and some
> state files you want in a lib directory.  say you want tool under
> </usr/local/>.
> do you prefer this layout:
>     /usr/local/etc/tool/...
>     /usr/local/lib/tool/...
> or this layout:
>     /usr/local/tool/etc/...
>     /usr/local/tool/lib/...
> and why?
> i know both work.  i've used both.  but i'm curious as to the reasons
> you fine folks choose one over the other.
> thanks,
> david
> --
> Live in a world of your own, but always welcome visitors.
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm

More information about the SanFrancisco-pm mailing list