Date: Fri, 13 Sep 2019 07:16:06 +0200 From: Polytropon <freebsd@edvax.de> To: Jim Trigg <jtrigg@huiekin.org> Cc: freebsd-questions@freebsd.org Subject: Re: A modest hier proposal Message-ID: <20190913071606.00aa3d63.freebsd@edvax.de> In-Reply-To: <ff67e062-a559-388c-cf91-edd83a278232@huiekin.org> References: <ff67e062-a559-388c-cf91-edd83a278232@huiekin.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 Sep 2019 23:50:40 -0400, Jim Trigg wrote:
> I recommend we reframe the directory structure. Since I'm sure I will
> get no support for merging the existing / and /usr trees to put all base
> items in / (/bin, /etc, /lib, /libexec, /share, /sbin), [...]
The structure documented in "man 7 hier" covers both historical aspects
and modern requirements. The status quo is a consensus of rules and
considerations, as is the naming of things.
> [...] I'm suggesting
> the following:
>
> /usr/local -> /pkg
> Explicitly define /opt for third-party software that is not in
> packages/ports.
Well, /opt is a Linuxism, and historically a Solarism, Solarisism,
which is explicitely not covered by FreeBSD definitions. Some users
use it to manage "non-ports 3rd party software" totally independently
from the rest of the system. Sometimes, /opt/bin exists and is part
of $PATH, and contains "call wrappers" for /opt/<something>, as there
is no structure defined for /opt - unlike for /usr/local, which more
or less replicates the top level structire of the OS, to be used by
3rd party software installed from ports, e. g.,
/usr/bin /usr/local/bin -> program executables
/usr/lib /usr/local/lib -> libraries
/usr/libexec /usr/local/libexec -> daemons
/usr/share /usr/local/share -> shared objects, data
/etc /usr/local/etc -> configuration
Programs are encouraged to use those directories. This is a recommendation
not always followed... ;-)
The difference between /<something> and /usr/<something> is again a
historical thing: Things that are required to get single-user mode up
and running, and things that are required for everything that leads
to more advanced modes, like multi-user, or graphical. Also partitioning
(i. e., having parts of the OS on different partitions that were
actually different disks) originates from a time where disk capacity
was too low to hold the full OS, so you'd have / on one disk to get
the OS up and running, and /usr/local on a different disk for all the
3rd party software the system runs - so the OS could get into a fully
functional state without /usr/local being present. You could even
swap different /usr/local disks (to revert to an older state or to
experimentally try new software). Of course, disk size is not a
concern today - as long as you don't enter the embedded space where
you even want to have things separated by "is read-only" and "can
be writte to", or "can be slow, is used only once" and "needs to
be faster, is used all the time".
Still using partitions (no matter of using ZFS or UFS) can have
advantages, like preventing /tmp from filling the whole disk from
some runaway process, or setting specific flags like noexec on a
partition for user data like /home where you explicitely want to
prevent the user from executing their own stuff.
> Explicitly define /local for locally developed software that has not
> been packaged as a port/package.
That's what people tend to use /opt for, as it does basically let
them do what they want - no rules. :-)
Of course, it's also possible to use "user-locally developed" software
from inside a user's home directory, where ~/bin is often present, and
~/.config is used by some programs.
> This leaves us with five areas:
> /{bin,etc,lib,libexec,share,sbin} - base software
> /usr/{bin,etc,lib,libexec,share,sbin} - base software
> /pkg/{bin,etc,lib,libexec,share,sbin} - ports/packages
> /opt/{bin,etc,lib,libexec,share,sbin} - third-party software that is not
> in ports/packages
> /local {bin,etc,lib,libexec,share,sbin} - locally developed software
> that has not yet been formalized into a port/package (with symlink from
> /usr/local?)
Interesting approach, but I think this is not going to happen. I know
certain Linux distributions tried to suggest a unified layout for to
be shared by all Linusi, but that didn't come true, likewise /Programs,
/Data, /ConfigurationAndSettings, and so on.
The general rule is: Everything under / belongs to the OS. 3rd party
software that is managed by pkg is entirely in /usr/local, and if
there should be anything else, it can go to /opt. /home is for users'
stuff, site rules might apply.
Do you remember PC-BSD (now TrueOS) and their packaging system? They
did something comparable: Every program gets its own directory subtree
with all stuff belonging to that program (plus its dependencies) in
only that directory subtree, with a "caller script" in a directory
that is in $PATH? I don't know if they still do that...
In my opinion, things will stay as they currently are - not entirely
perfect, but understandable and predictable as soon as you have
successfully understood the rules and considerations.
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190913071606.00aa3d63.freebsd>