From c520ef972c7e49dd54857a2f4504da06de4f2cc5 Mon Sep 17 00:00:00 2001 From: Colin Walters Date: Mon, 30 Jan 2017 06:04:41 +0100 Subject: [PATCH] Rename to nts MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is in concert with https://github.com/ostreedev/ostree/pull/659. We can now talk coherently about `nts` when that's what we mean, rather than just the base libostree. I've heard many people talk about "ostree layering", but no such thing exists 😃. Also, `nts` is just shorter to say, and type, etc. It's a net-new brand, but I think that's OK. Obviously, there's a lot more changes we could do here, but I don't want to create conflicts, just start the ball rolling. --- configure.ac | 4 ++-- docs/index.md | 41 ++++++++++++++++++++++------------------- 2 files changed, 24 insertions(+), 21 deletions(-) diff --git a/configure.ac b/configure.ac index ff10bfa283..641998d068 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_PREREQ([2.63]) -AC_INIT([rpm-ostree], [2017.1], [walters@verbum.org]) +AC_INIT([nts], [2017.1], [walters@verbum.org]) AC_CONFIG_HEADER([config.h]) AC_CONFIG_MACRO_DIR([buildutil]) AC_CONFIG_AUX_DIR([build-aux]) @@ -123,7 +123,7 @@ AM_CONDITIONAL(BUILDOPT_INSTALL_TESTS, test x$enable_installed_tests = xyes) AC_ARG_ENABLE(new-name, AS_HELP_STRING([--enable-new-name], [Install additionally as nts (default: no)]),, - [enable_new_name=no]) + [enable_new_name=yes]) AM_CONDITIONAL(BUILDOPT_NEW_NAME, test x$enable_new_name = xyes) AC_ARG_WITH(bubblewrap, diff --git a/docs/index.md b/docs/index.md index 5123700a93..b994c526d6 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,12 +1,16 @@ -# What is rpm-ostree? +# What is nts? (formerly rpm-ostree) -rpm-ostree is a hybrid image/package system. It uses -[OSTree](https://ostree.readthedocs.io/en/latest/) as a base image -format, and accepts RPM on both the client and server side, sharing -code with the [dnf](https://en.wikipedia.org/wiki/DNF_(software)) project; -specifically [libhif](https://github.com/rpm-software-management/libhif). +`nts` is a hybrid image/package system, designed for the Fedora/CentOS +ecosystem. It was formerly known as `rpm-ostree`. `nts` builds on top of two +shared libraries, [libOSTree](https://ostree.readthedocs.io/en/latest/) for +image-like atomic +upgrades, [libdnf](https://github.com/rpm-software-management/libdnf) for +package management. -# Getting started +NOTE: In much of the rest of this documentation, we will refer to `rpm-ostree`; +it's expected that the naming transition will occur slowly over time. + +# Getting it If you want to try the system as a user, we recommend [Project Atomic](http://www.projectatomic.io/). If you are @@ -15,20 +19,19 @@ interested in assembling your own systems, see # Why would I want to use it? -One major feature rpm-ostree has over traditional package management -is atomic upgrade/rollback. It supports a model where an OS vendor -(such as [CentOS](https://www.centos.org/) or -[Fedora](https://getfedora.org/) can provide pre-assembled "base OS -images", and client systems can replicate those, and possibly layer on -additional packages. +Unlike traditional package managers, `nts` defaults to using +an atomic upgrade model from a pre-assembled tree. Client systems +replicate this from a server, and *no package management* is +performed on the client side. For example, we do not download the +yum/dnf repodata, and no dependency resolution is performed. -rpm-ostree is a core part of the [Project Atomic](http://www.projectatomic.io/) -effort, which uses rpm-ostree to provide a minimal host for -Docker formatted Linux containers. +However, one can use `nts install` to dynamically layer on additional +packages on the client side. This ends up with a hybrid blend +between traditional image systems, and package management. -We expect most users will be interested in rpm-ostree on the client -side, using it to replicate a base system, and possibly layer on -additional packages, and use containers for applications. +Of course, for Project Atomic, the focus of Atomic Host is on +installing applications in containers, but we believe package +layering is an essential bridge. # Why not implement these changes in an existing package manager?