rpm-ostree 2016.4: https://github.com/projectatomic/rpm-ostree/releases/tag/v2016.4
is now in Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2016-2b9342c5cc https://bodhi.fedoraproject.org/updates/FEDORA-2016-bfecf6abed Remember, to try it, you can rebase an existing Atomic Host system using: https://fedoraproject.org/wiki/QA:Updates_Testing (Also in our CentOS devel stream: https://wiki.centos.org/SpecialInterestGroup/Atomic/Devel ) This release has a number of changes, but as the git tag says, I think the package layering that we have now finally brings into focus a long-held goal. Before, the rpm-ostree component of the [Project Atomic](http://www.projectatomic.io/) effort was - as a downstream user - something that kind of faded into the background underneath the `atomic host` command line. We primarily exposed `atomic host {upgrade,rollback}` and later `deploy`: https://blog.verbum.org/2015/12/15/new-atomic-host-verb-rpm-ostree-deploy/ However, beyond that one's interaction with it as a system consumer was limited. Now, containerization has progressed significantly in many areas, but as I mention here: https://fedorapeople.org/~walters/2016.06-rhsummit-systemcontainers/#/6/1 I think package layering is essentially a better model for "system extensions" or code that's required to run in the host context. To repeat, rpm-ostree always said in the `README.md` that it was intending to be a hybrid package/image system - to bridge the worlds[1] between traditional package managers and ChromeOS style dm-verity/dual-partition style approaches. Now that vision is here. What we're really building is something that links to both libdnf[2] and libostree, carrying forwards the parts of RPM that are OK, while having a completely new implementation for things like filesystem interaction and %post scripts. librpm isn't involved in writing to disk, libostree is - and libostree doesn't have bugs around replacing symlinks with directories or require directory ownership, for example. We always generate a *new* root on changes which ensures each change is clean and doesn't carry baggage from previous updates. Another thing I think is cool is that we use bubblewrap[3] to run %post scripts, which greatly helps avoid system damage from badly written scripts, and helps ensure that system changes are under control of rpm-ostree. At the same time though, we've built up a community of people who are using rpm-ostree to make custom systems (the "full server side compose" or "I want to do my own Atomic Host/Chromebook" model), and we will continue to fully support this as well. There's a lot more to do - my intention is to continue driving forwards rpm-ostree in Fedora (and CentOS) as an alternative systems management tool. At the same time, we end up sharing a lot of code with dnf, and the teams communicate regularly, so things like /etc/yum.repos.d will continue to be fully compatible between the two. The package layering implementation ended up finally intersecting the "librpm" and "libostree" in the code as well - which in turn is going to unlock many features such as *much* faster server side composes, and others. So I think it's a great time to take another look at rpm-ostree and see where we are and where we're going. [1] https://ostree.readthedocs.io/en/latest/manual/related-projects/ [2] https://github.com/rpm-software-management/libhif/pull/165#issuecomment-231667503 [3] https://github.com/projectatomic/bubblewrap -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
