On 1/3/07, Dave Ewart <[EMAIL PROTECTED]> wrote:
One thing I'm curious about is managing locally-maintained applications.
Under Debian, anything that was core to the system went into /usr/bin,
as did any Debian-supplied packages. In Debian, the location /usr/local
is, by policy, never touched by the OS at all, allowing its contents to
be preserved over reinstalls, or at least backed-up and managed
separately from everything else supplied with the OS.
With OpenBSD, it seems to work like this:
/usr/bin - 'core' utilities/executables
/usr/local/bin - executables from OpenBSD packages (and presumably ports
too, althougth I've only used packages to date)
Where is the right place to install/locate a non-distributed
application, say, 'myapp'? I'm working under the assumption that there
is a generally-considered Right Place for this sort of thing.
From an installed app perspective, ports and packages are the same. In
actuality, installing from a port does nothing more than building a
package and then installing the package.
As for where to install a third-party application, /usr/local/ is the
directory tree that tends to root apps not part of the base OS.
Typical exceptions to this are that /etc/ usually ends up with the
config files and some things end up in /var/ such as logs, pid files,
etc.
You'll also commonly find applications stuck in /usr/local/myapp/ for
example, to keep them contained and not scattered across
/usr/local/{bin,sbin,share,lib,...}. You'll also find apps set up with
/usr/local/ as the destination dir so that you DO end up with stuff
scattered to the appropriate subdirectories there. There's no hard
fast rules, more convention. It seems more important to keep stuff
rooted under /usr/local/ *somehow* and to make sure you don't have it
intermingled with the core OS. Exactly how isn't a matter of great
debate.
You might take a look at some ports and see how they install and where
to. You might also consider just using packages where possible, and
creating ports for applications that we don't have ports for (much
easier in the long run.)
DS
