73f2a7f058
Various OS "diff" methods can run concurrently with whatever else is going on since they don't have to obtain the system root lock. Just to make sure there's no conflicts when writing deployments or downloading RPM package details, use an internal reader/writer lock to protect the critical sections of upgrade, rebase, rollback, etc. |
||
---|---|---|
buildutil | ||
design | ||
doc | ||
libglnx@0cf50c6735 | ||
man | ||
packaging | ||
scripts | ||
src | ||
tests | ||
.gitignore | ||
.gitmodules | ||
autogen.sh | ||
configure.ac | ||
COPYING | ||
Makefile-daemon.am | ||
Makefile-decls.am | ||
Makefile-lib-defines.am | ||
Makefile-lib.am | ||
Makefile-libpriv.am | ||
Makefile-man.am | ||
Makefile-rpm-ostree.am | ||
Makefile-tests.am | ||
Makefile.am | ||
README.md | ||
TODO |
rpm-ostree
A system to compose RPMs on a server side into an OSTree repository, and a client side tool to perform updates.
The project aims to bring together a hybrid of image-like upgrade features (reliable replication, atomicity), with package-like flexibility (seeing package sets inside trees, layering, partial live updates).
rpm-ostree is in beta!
While many of the underlying technologies here are stable, if you are considering using this in your organization, you should perform a careful evaluation of the whole stack. Software updates are obviously critical, and touch on many areas of concern.