Quoting Miroslav Skoric (skoric@???):
> Possibly ... but you need to explain that to the 3rd party software
> programmers. All I have remembered to be compiled from sources
> locally, went to /usr/local/.. Seems as (un)written consensus;
> however nobody suggested to have /usr/local/ as a separate partition
> at install.
Nobody _you_ heard, perhaps, but it's routinely done by us server admins,
as there are compelling advantages, e.g., with /usr/local being distinct
from /usr, you can have different sets of mount options. Here's how I
designed /etc/fstab on a typical server I constructed in the middle
2000s:
# <file system> <mount point> <type> <options> <dump> <pass>
## sda is (obviously) the boot drive. 73 GB SCSI.
/dev/sda1 /boot ext2 defaults 0 2
/dev/sda5 none swap sw 0 0
/dev/sda6 /var ext2 noatime,nodev,nosuid 0 2
/dev/sda7 / ext3 defaults,errors=remount-ro 0 1
/dev/sda8 /recovery ext3 defaults 0 2
/dev/sda9 /usr ext2 nodev,ro 0 2
## sdb and sdc are RAID1 mirrored, except for swap. Each is 18 GB SCSI.
/dev/md0 /var/www ext3 nodev,nosuid 0 2 #sdb5,sdc5
/dev/md1 /var/lib ext3 nodev 0 2 #sdb6,sdc6
/dev/md2 /var/spool ext3 defaults 0 2 #sdb7,sdc7
/dev/sdb8 none swap sw 0 0
/dev/sdc8 none swap sw 0 0
/dev/md3 /home ext3 defaults 0 2 #sdb9,sbc9
/dev/md4 /usr/local ext3 defaults 0 2 #sdb10,sdc10
These days, I would do it quite differently, especially on account of
using SSDs instead of hard drives, so, e.g., there's no need to group
filesystems to minimise average seek distance/time on an SSD that
inherently doesn't need to perform seek operations in the first place.
However, as a detail of the above, notice that /usr is normally mounted
read-only, while /usr/local is not. This different requires that they
be distinct filesystems. (/usr is also ext2 in this example, as there's
no advantage to the overhead of journaling on a filesystem left normally
read-only.)
In case people are wondering, details of how to keep /usr mounted
read-only and still let apt work correctly without manual intervention
can be found here:
http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg00212.html
Having /usr normally unmounted is an example of routine caution
against likely failure modes: That filesystem is where almost all
system programs and libs live, and on a typical Linux system is (at
least by default and initially) where most of its complexity and disk
usage is. It is a tree you as local system administrator wish to
protect against mishap. The most likely source of such mishap is:
you, the local system administrator.
I have /usr normally unmounted in order to have in place a first-level
default protection against the worst threat to its orderly management
and contents, i.e., against myself. If I am careless with the root-user
account and launch a recursive chown of something that would cascade
down /usr, for example, it will (by design) fail.
Pretty much the only time /usr needs to be mounted read-write is during
package operations. For that exact reason, I have a pair of scripts
invoked via dpkg hooks (see debian-devel link, above) that remount /usr
read-write just before packages get installed or removed, and then
remount it read-only again immediately when the package operations are
done.