mirror of
https://github.com/ostreedev/ostree.git
synced 2025-01-06 17:18:25 +03:00
92b1a27202
In the OSTree model, executables go in `/usr`, state in `/var` and configuration in `/etc`. Software that lives in `/opt` however messes this up because it often mixes code *and* state, making it harder to manage. More generally, it's sometimes useful to have the OSTree commit contain code under a certain path, but still allow that path to be writable by software and the sysadmin at runtime (`/usr/local` is another instance). Add the concept of state overlays. A state overlay is an overlayfs mount whose upper directory, which contains unmanaged state, is carried forward on top of a lower directory, containing OSTree-managed files. In the example of `/usr/local`, OSTree commits can ship content there, all while allowing users to e.g. add scripts in `/usr/local/bin` when booted into that commit. Some reconciliation logic is executed whenever the base is updated so that newer files in the base are never shadowed by a copied up version in the upper directory. This matches RPM semantics when upgrading packages whose files may have been modified. For ease of integration, this is exposed as a systemd template unit which any downstream distro/user can enable. The instance name is the mountpath in escaped systemd path notation (e.g. `ostree-state-overlay@usr-local.service`). See discussions in https://github.com/ostreedev/ostree/issues/3113 for more details. |
||
---|---|---|
.. | ||
auto-prune.sh | ||
basic-misc.sh | ||
boot-automount.sh | ||
data | ||
deployment-lint | ||
finalization.sh | ||
itest-bare-root.sh | ||
itest-deploy-selinux.sh | ||
itest-label-selinux.sh | ||
kargs-edit-in-place.sh | ||
overlay-initrds.sh | ||
staged-delay.sh | ||
staged-deploy.sh | ||
state-overlay.sh | ||
unlock-transient.sh | ||
var-mount.sh | ||
var-tmpfiles.sh |