From a89d011c0b4ce73f4b48e1563ca7044cdfa9e0eb Mon Sep 17 00:00:00 2001 From: Kelvin Fan Date: Thu, 15 Oct 2020 19:51:44 -0400 Subject: [PATCH] docs: Fix various typos --- docs/atomic-upgrades.md | 8 ++++---- docs/buildsystem-and-repos.md | 8 ++++---- docs/deployment.md | 2 +- docs/formats.md | 7 +++---- docs/repo.md | 6 +++--- docs/repository-management.md | 3 +-- 6 files changed, 16 insertions(+), 18 deletions(-) diff --git a/docs/atomic-upgrades.md b/docs/atomic-upgrades.md index 3ddd8b40cf..f4b31acaa2 100644 --- a/docs/atomic-upgrades.md +++ b/docs/atomic-upgrades.md @@ -30,14 +30,14 @@ the remote server. Suppose we're tracking a ref named which contains a SHA256 checksum. This determines the tree to deploy, and `/etc` will be merged from currently booted tree. -If we do not have this commit, then, then we perform a pull process. +If we do not have this commit, then we perform a pull process. At present (without static deltas), this involves quite simply just fetching each individual object that we do not have, asynchronously. Put in other words, we only download changed files (zlib-compressed). Each object has its checksum validated and is stored in `/ostree/repo/objects/`. -Once the pull is complete, we have all the objects locally -we need to perform a deployment. +Once the pull is complete, we have downloaded all the objects that we need +to perform a deployment. ## Upgrades via external tools (e.g. package managers) @@ -50,7 +50,7 @@ locally, etc. At a practical level, most package managers today (`dpkg` and `rpm`) operate "live" on the currently booted filesystem. The way they could -work with OSTree is instead to take the list of installed packages in +work with OSTree is to, instead, take the list of installed packages in the currently booted tree, and compute a new filesystem from that. A later chapter describes in more details how this could work: [Adapting Existing Systems](adapting-existing.md). diff --git a/docs/buildsystem-and-repos.md b/docs/buildsystem-and-repos.md index 6d506b4eb4..e265ee7a03 100644 --- a/docs/buildsystem-and-repos.md +++ b/docs/buildsystem-and-repos.md @@ -21,10 +21,10 @@ primarily on server-side concerns. ## Build vs buy Therefore, you need to either pick an existing tool for writing -content into an OSTree repository, or to write your own. An example -tool is [rpm-ostree](https://github.com/projectatomic/rpm-ostree) - it -takes as input RPMs, and commits them (currently oriented for a server -side, but aiming to do client side too). +content into an OSTree repository, or write your own. An example +tool is [rpm-ostree](https://github.com/coreos/rpm-ostree) - it +takes as input RPMs, and commits them (currently oriented for +server-side, but aiming to do client-side too). ## Initializing diff --git a/docs/deployment.md b/docs/deployment.md index 1ea7ea4602..30323f8cc8 100644 --- a/docs/deployment.md +++ b/docs/deployment.md @@ -26,7 +26,7 @@ at a time; each deployment is intended to be a target for Each deployment is grouped in exactly one "stateroot" (also known as an "osname"); the former term is preferred. -From above, you can see that an stateroot is physically represented in the +From above, you can see that a stateroot is physically represented in the `/ostree/deploy/$stateroot` directory. For example, OSTree can allow parallel installing Debian in `/ostree/deploy/debian` and Red Hat Enterprise Linux in `/ostree/deploy/rhel` (subject to operating system support, present released diff --git a/docs/formats.md b/docs/formats.md index 36d395bda1..0943aafa6c 100644 --- a/docs/formats.md +++ b/docs/formats.md @@ -103,12 +103,11 @@ Since static deltas may not exist, the client first needs to attempt to locate one. Suppose a client wants to retrieve commit `${new}` while currently running `${current}`. -The first thing to understand is that in order to save space, these -two commits are "modified base64" - the `/` character is replaced with -`_`. +In order to save space, these two commits are "modified base64" - the +`/` character is replaced with `_`. Like the commit objects, a "prefix directory" is used to make -management easier for filesystem tools +management easier for filesystem tools. A delta is named `$(mbase64 $from)-$(mbase64 $to)`, for example `GpTyZaVut2jXFPWnO4LJiKEdRTvOw_mFUCtIKW1NIX0-L8f+VVDkEBKNc1Ncd+mDUrSVR4EyybQGCkuKtkDnTwk`, diff --git a/docs/repo.md b/docs/repo.md index 5cc59bf1f0..9b254b1292 100644 --- a/docs/repo.md +++ b/docs/repo.md @@ -39,7 +39,7 @@ regenerate it from source code. A dirtree contains a sorted array of (filename, checksum) pairs for content objects, and a second sorted array of (filename, dirtree checksum, dirmeta checksum), which are -subdirectories. These type of objects are stored as files +subdirectories. This type of object is stored as files ending with `.dirtree` in the objects directory. ### Dirmeta objects @@ -56,7 +56,7 @@ Unlike the first three object types which are metadata, designed to be `mmap()`ed, the content object has a separate internal header and payload sections. The header contains uid, gid, mode, and symbolic link target (for symlinks), as well as extended attributes. After the -header, for regular files, the content follows. These parts toghether +header, for regular files, the content follows. These parts together form the SHA256 hash for content objects. The content type objects in this format exist only in `archive` OSTree repositories. Today the content part is gzip'ed and the objects are stored as files ending @@ -102,7 +102,7 @@ systems. The `bare-user-only` mode is a variant to the `bare-user` mode. Unlike `bare-user`, neither ownership nor extended attributes are stored. These repos are meant to to be checked out in user mode (with the `-U` flag), where this -information is not applied anyway. Hence this mode may loose metadata. +information is not applied anyway. Hence this mode may lose metadata. The main advantage of `bare-user-only` is that repos can be stored on filesystems which do not support extended attributes, such as tmpfs. diff --git a/docs/repository-management.md b/docs/repository-management.md index 11fe2f40de..41b8d2b153 100644 --- a/docs/repository-management.md +++ b/docs/repository-management.md @@ -106,8 +106,7 @@ want to "promote" that commit. Let's create a new branch called complete system. This might be where human testers get involved, for example. -A basic way to "promote" the `buildmaster` commit that passed -testing like this: +This is a basic way to "promote" the `buildmaster` commit that passed testing: ``` ostree commit -b exampleos/x86_64/smoketested/standard -s 'Passed tests' --tree=ref=aec070645fe53...