3190eff276
The high level goal is to deprecate libgsystem. I was trying to share code between ostree/rpm-ostree, but it was too painful to commit to forver frozen ABI for new utility APIs. The git submodule approach will much more easily allow breaking API/ABI, and iterate on APIs until they either land in GLib or not. Note that libglnx will not use GFile*, so a full port to it will involve also not using that. Thus, it will be necessarily incremental; in the meantime we'll link to both libgsystem and libglnx. |
||
---|---|---|
buildutil | ||
design | ||
doc | ||
libglnx@ba67dd39a7 | ||
man | ||
packaging | ||
scripts | ||
src | ||
tests | ||
.gitignore | ||
.gitmodules | ||
autogen.sh | ||
configure.ac | ||
COPYING | ||
Makefile-decls.am | ||
Makefile-man.am | ||
Makefile-rpm-ostree.am | ||
Makefile-tests.am | ||
Makefile.am | ||
README.md | ||
TODO |
rpm-ostree, aka /usr/bin/atomic
An 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.