1

doc/GlobalSpec.md

@@ -1,9 +1,9 @@
-Repository / global configuration
-=================================
+GlobalSpec (repository config)
+==============================
 
-The repository config (also called the global config) is the central starting point for all operations.
-It basically declares what should be built into the final installable package repository. Usually placed
-under `cf/repos/`. 
+The repository config (also called the global config) is the central starting point for all
+operations. It basically declares what should be built into the final installable package
+repository. Usually placed under `cf/repos/`.
 
 ### Root level keys:
 
@@ -15,35 +15,38 @@ packages | Lists the packages that can be built
 pools    | The repo pools and their packages
 
 
-Internally, this config is stored into the global scope. It's fields can be referenced from other scopes
-via the `GLOBAL::` prefix.
+Internally, this config is stored into the global scope. It's fields can be referenced from
+other scopes via the `GLOBAL::` prefix.
 
 Targets section
 ---------------
 
-We can build installable repos for several distros in one pass. The `targets` list *(list of strings)*
-defines which targets shall be used. Settings for individual targets defined under `cf/targets`.
+We can build installable repos for several distros in one pass. The `targets` list
+*(list of strings)* defines which targets shall be used. Settings for individual targets defined
+under `cf/targets`.
 
-If predefined targets aren't sufficient, additional ones can be configured by adding appropriate target
-config yaml files.
+If predefined targets aren't sufficient, additional ones can be configured by adding appropriate
+target config yaml files.
 
-Note that different cpu architectures also imply different targets. In order to support classic multiarch
-repos *(as most dpkg based distros do)*, the predefined targets are configured to place their output
-into the same, per-distro, repository.
+Note that different cpu architectures also imply different targets. In order to support classic
+multiarch repos *(as most dpkg based distros do)*, the predefined targets are configured to place
+their output into the same, per-distro, repository.
 
-Example: the targets `devuan/daedalus/i386` and `devuan/deadalus/amd64` will both use target repo name `devuan/daedalus`
+Example: the targets `devuan/daedalus/i386` and `devuan/deadalus/amd64` will both use target repo
+name `devuan/daedalus`
 
 Pools section
 -------------
 
-In order to support different building multiple repos with different package subsets, we can configure
-separate pools. These are listed as subkeys under the `pools` root key. Each pool defines a list of
-primary packages *(key "packages")* it should contain. If those also define dependencies, these will be
-added automatically, thus being built and landing the installable repo.
+In order to support different building multiple repos with different package subsets, we can
+configure separate pools. These are listed as subkeys under the `pools` root key. Each pool
+defines a list of primary packages *(key "packages")* it should contain. If those also define
+dependencies, these will be added automatically, thus being built and landing the repo.
 
 Most cases *(for now)* should be sufficient w/ just one pool, named `default`.
 
-The path of the finally installable repo will be a subdir, named by the pool, under the per-target directory.
+The path of the finally installable repo will be a subdir, named by the pool, under the
+per-target directory.
 
 For future releases it is planned to support importing of pools into others: in this case, the per-package
 build job will also add the imported pool's target repo *(so it's packages can be directly used)* and skip