Re: [gentoo-dev] usr merge

[Rich Freeman]

On Thu, Apr 7, 2016 at 10:44 PM, M. J. Everitt <m.j.everitt@×××.org> wrote:
> 2) "Today, a separate /usr partition already must be mounted by the
> initramfs during early boot, thus making the justification for a
> split-off moot." - no, not all gentoo users have an initramfs and
> need/want one .. so this is a false assumption.

You only need an initramfs (or some other mechanism to mount /usr
during early boot) if /usr is on a different filesystem than /.

If /usr is a separate filesystem, then Gentoo does require that it be
mounted during early boot, at least as a supported configuration.
While it is true today that with some configurations you can probably
get away with not mounting it during early boot, there is no
requirement that package maintainers support this.  That includes
system packages.

So, #2 applies to Gentoo as much as to any other distro.  That was a
topic of some debate a few years ago now.

> 3) I still believe there is merit in distinguishing between binaries
> that can/should be run as root, and those that can/should not. Those
> that run as root 100% of the time, or use VMs, don't really 'use' linux
> in the original sense of the OS ..

Duncan already explained much of this, but if you're relying on a
user's PATH setting to prevent security issues you're doing it wrong.
There are a number of binaries in /sbin which are completely
appropriate for a non-privileged user to execute.  Besides
non-privileged operations of binaries like btrfs or rpcinfo, there are
a bunch of misc binaries in there like usleep or zdump.

Really though the main point of merging these paths into /usr is to
get all the static content of a distro into a single path, which can
then be maintained as a read-only filesystem, mounted across multiple
systems, protected using tripwire or signature checking, and so on.
As has been pointed out the rolling release nature of Gentoo reduces
some of these benefits somewhat.  To truly get these benefits we would
also need to rethink how post-install configuration gets managed as
was already pointed out.

However, the principle is still a potentially useful one even if we
never follow-up with some of the things Fedora/etc are doing.  After a
merge the package manager has free rein over /usr, full config
management is the policy in /etc, and /var is a place for persistent
state that generally belongs to the applications themselves (but
management of this is a bit of a mix still with stuff like /var/www
and /var/bind alongside mail spools and mysql database files).

-- 
Rich