Update naming in docs

doc/toolchain/index.rst

@@ -7,7 +7,7 @@ VM building and packaging
    vm-creation
    abuild
    lxc-overview
-   lxc-build
+   lxcbuild
    lxc-pack
    pkgmgr
    vmmgr-hooks

doc/toolchain/lxc-build.md

@@ -2,18 +2,18 @@
 
 ## Overview
 
-`lxc-build` utility creates a LXC container based on its build recipe and build context path given in command line parameter. If a filename is given, the build recipe is loaded from the file and the directory in which the file resides is taken as build context, ie. all relative paths are resolved from it. In case a directory path is passed as parameter, the directory is then used as build context and a file called `lxcfile` from the given directory is used as build recipe.
+`lxcbuild` utility creates a LXC container based on its build recipe and build context path given in command line parameter. If a filename is given, the build recipe is loaded from the file and the directory in which the file resides is taken as build context, ie. all relative paths are resolved from it. In case a directory path is passed as parameter, the directory is then used as build context and a file called `lxcfile` from the given directory is used as build recipe.
 
 ### Usage
 
 ```bash
-lxc-build <buildpath>
+lxcbuild <buildpath>
  where the buildpath can be either specific lxcfile or a directory containing one
 ```
 
 ## Directives used in lxcfile
 
-The *lxcfile* syntax is designed to resemble *Dockerfile* syntax in order to ease the potential transition. Since LXC operates on much lower level of abstraction than Docker, some principles are applied more explicitly and verbosely. Major difference between Docker and *lxc-build* is that every directive in *Dockerfile* creates a new filesystem layer whereas layers in *lxc-build* are managed manually.
+The *lxcfile* syntax is designed to resemble *Dockerfile* syntax in order to ease the potential transition. Since LXC operates on much lower level of abstraction than Docker, some principles are applied more explicitly and verbosely. Major difference between Docker and *lxcbuild* is that every directive in *Dockerfile* creates a new filesystem layer whereas layers in *lxcbuild* are managed manually.
 
 ### IMAGE
 
@@ -29,9 +29,9 @@ The *lxcfile* syntax is designed to resemble *Dockerfile* syntax in order to eas
 - **Docker equivalent:** `FROM`
 - **Populates LXC field:** `lxc.rootfs.path`
 
-### FIXLAYER
+### MERGE
 
-- **Usage:** `FIXLAYER <scriptname>`
+- **Usage:** `MERGE <scriptname>`
 - **Description:** Runs `<scriptname>` on LXC host and passes all layer paths as parameter to this script. This helps you to resolve the conflicts in cases where you mix multiple OverlayFS layers with overlapping files, ie. package manager cache. The idea is that all layers are read separately by the `<scriptname>` script and the fixed result is written back to the uppermost layer.
 - **Docker equivalent:** None
 - **Populates LXC field:** None
@@ -119,7 +119,7 @@ The *lxcfile* syntax is designed to resemble *Dockerfile* syntax in order to eas
 
 ## LXC config
 
-Although *lxcfile* populates some LXC config fields, there are lot of defaults with remain unchanged. The template file to which *lxc-build* fills in the values looks as follows:
+Although *lxcfile* populates some LXC config fields, there are lot of defaults with remain unchanged. The template file to which *lxcbuild* fills in the values looks as follows:
 
 ```bash
 # Image name

doc/toolchain/lxc-overview.md

@@ -28,7 +28,7 @@ Due to the Docker's approach, storage overlay layers cannot be easily managed by
 
 Finally, Docker maintainers explicitly refuse to implement a possibility to isolate the docker daemon to private Docker repositories (registries) in the community edition of Docker. It is possible to have some custom and even private repositories, but it is not possible to deactivate the default public *Dockerhub*.
 
-The downsides of using LXC is that its usage requires a bit more knowledge about how the linux containers actually work, and that most 3rd party applications are distributed using `Dockerfile`, which requires rewriting into LXC, however this is simplified by the [`lxc-build`](lxc-build) tool, which aims to automatize LXC container building using *Dockerfile*-like syntax.
+The downsides of using LXC is that its usage requires a bit more knowledge about how the linux containers actually work, and that most 3rd party applications are distributed using `Dockerfile`, which requires rewriting into LXC, however this is simplified by the [`lxcbuild`](lxcbuild) tool, which aims to automatize LXC container building using *Dockerfile*-like syntax.
 
 ## Container interfaces
 

doc/toolchain/lxc-pack.md

@@ -4,7 +4,7 @@
 
 The `lxc-pack` utility creates a `.tar.xz` archives based on package metadata and manages the `packages.json` repository metadata file. If a filename is passed as command line parameter to `lxc-pack`, the metadata are loaded from the file. In case a directory path is given, the metadata are loaded from a file called `pkg` from the directory. All metadata files are in JSON format.
 
-The product of *lxc-build* command described in LXC building documentation can be used in its entirety, ie. both filesystem layer and configuration, or only as dependency, in which case the container configuration is omitted and only the filesystem layer is used. Apart from that, the package can contain installation, upgrade and uninstallation script and data, all of which are optional. Accepted names are
+The product of *lxcbuild* command described in LXC building documentation can be used in its entirety, ie. both filesystem layer and configuration, or only as dependency, in which case the container configuration is omitted and only the filesystem layer is used. Apart from that, the package can contain installation, upgrade and uninstallation script and data, all of which are optional. Accepted names are
 
 - `install.sh` file and `install` directory for post-install scripts.
 - `upgrade.sh` file and `upgrade` directory for post-upgrade scripts.

doc/toolchain/vm-creation.md

@@ -58,7 +58,7 @@ There are 3 distinct packaging systems.
 
 1. Just a plain tar for basic OS setup used by `vm.sh` installation script.
 2. [Abuild](abuild) for the native Alpine linux packages (APK) used for ACME client and VMMgr packaging.
-3. [`lxc-build`](lxc-build) / [`lxc-pack`](lxc-pack) for LXC container building and packaging.
+3. [`lxcbuild`](lxcbuild) / [`lxc-pack`](lxc-pack) for LXC container building and packaging.
 
 Before any building and packaging can be started, build toolchain including signing keys needs to be set up. This is done via `install-toolchain.sh` script.
 

doc/toolchain/vmmgr-hooks.md

@@ -26,7 +26,7 @@ Where the `application` is the internal application name, same as previously use
 
 ## LXC hooks
 
-LXC hooks set various environment variables prior to calling the defined executables. For overview of native LXC hooks, see section *Container hooks* in the official [lxc.container.conf(5) documentation](https://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html). All hooks mentioned in this chapter are hardcoded in the container configuration via a template used by[`lxc-build`](lxc-build).
+LXC hooks set various environment variables prior to calling the defined executables. For overview of native LXC hooks, see section *Container hooks* in the official [lxc.container.conf(5) documentation](https://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html). All hooks mentioned in this chapter are hardcoded in the container configuration via a template used by[`lxcbuild`](lxcbuild).
 
 ### prepare-container