Why the complex layout for the operating system?

[Giovanni Campagna <scampa giovanni gmail com>]

I just saw https://live.gnome.org/OSTree/DeploymentModel2, and I
noticed that despite the new deployment model, there is still a lot of
complexity.
Now, ostree is no longer meant to be parallel installed with existing
distributions (only virtual machines are supported), so there is space
for a simpler solution if we control the root filesystem.

What I envision is:
- the root filesystem is static read-only (created by ostree admin
init) and contains
  /ostree -> directory
  /boot -> rw mount point to boot disk
  /usr -> ro bind mount to /ostree/deploy/$OS/$ACTIVE
  /usr/local -> symlink to /opt/local
  /etc -> rw bind mount to /ostree/deploy/$OS/$ACTIVE-etc
  /lib -> symlink to /usr/lib
  /bin -> symlink to /usr/bin
  /sbin -> symlink to /usr/sbin
  /var -> rw bind mount to /ostree/deploy/$OS/var
  /opt -> symlink to /var/opt
  /srv -> symlink to /var/srv
  /home -> directory or rw mount point to home disk

- at build, packages are configured with --prefix=/usr
--sysconfdir=/etc --localstatedir=/var, but only what they install in
/usr and /etc is added to the repo, everything else is discarded
  (the static rootfs layout is recreated in the build chroot by ostbuild)
- the repo thus contains /bin, /lib, /etc, /sbin, ... but no /usr or /var
- the contents of /boot are stored inside /usr/boot (or /usr/lib/boot)
and moved to the boot partition by ostree admin

The advantage of this simpler model is that the are no bind mounts
going outside the visible folder hierarchy (which is easier to
understand for developers) and there are no shadowed folders, chroots
or move mounts of /. Also, there are no shadowed directories in the
deployment, which creates confusion and hides bug.

I know this is an invasive change, as you need to rewrite the ostree
loader and ostbuild, but I believe this simplification is worth the
change.
As always, comments appreciated.

Giovanni