Fix broken links (#316)

* Fix broken links

* A few more broken links

Signed-off-by: Mauro Morales <mauro.morales@spectrocloud.com>

Signed-off-by: Mauro Morales <mauro.morales@spectrocloud.com>

docs/content/en/docs/Concepts/Overview/_index.md

@@ -28,6 +28,6 @@ Luet allows also to create packages entirely from Docker images content. In this
 
 ## Package definitions
 
-Luet uses [YAML](https://en.wikipedia.org/wiki/YAML) for the package specification format, Luet parses the [requirements](/docs/docs/concepts/overview/constraints) to build [packages](/docs/docs/concepts/packages), so Luet can consume them.
+Luet uses [YAML](https://en.wikipedia.org/wiki/YAML) for the package specification format, Luet parses the [requirements](/docs/concepts/overview/constraints) to build [packages](/docs/concepts/packages), so Luet can consume them.
 
 Below you can find links to tutorials on how to build packages, images and repositories.

docs/content/en/docs/Concepts/Overview/build_packages.md

@@ -32,11 +32,11 @@ Luet provides an abstraction layer on top of the container image layer to make t
 
 To resolve the dependency tree Luet uses a SAT solver and no database. It is responsible for calculating the dependencies of a package and to prevent conflicts. The Luet core is still young, but it has a comprehensive test suite that we use to validate any future changes.
 
-Building a package with Luet requires only a [definition](/docs/docs/concepts/packages/specfile). This definition can be self-contained and be only composed of one [specfile](/docs/docs/concepts/packages/specfile), or a group of them, forming a Luet tree. For more complex use-cases, see [collections](/docs/docs/concepts/packages/collections). Luet also supports building packages from standard `Dockerfile` directly.
+Building a package with Luet requires only a [definition](/docs/concepts/packages/specfile). This definition can be self-contained and be only composed of one [specfile](/docs/concepts/packages/specfile), or a group of them, forming a Luet tree. For more complex use-cases, see [collections](/docs/concepts/packages/collections). Luet also supports building packages from standard `Dockerfile` directly.
 
 Run `luet build --help` to get more help for each parameter.
 
-Build accepts a list of packages to build, which syntax is in the `category/name-version` notation. See also [specfile documentation page](/docs/docs/concepts/packages/specfile/#refering-to-packages-from-the-cli) to see how to express packages from the CLI.
+Build accepts a list of packages to build, which syntax is in the `category/name-version` notation. See also [specfile documentation page](/docs/concepts/packages/specfile/#refering-to-packages-from-the-cli) to see how to express packages from the CLI.
 
 ## Reproducible builds
 
@@ -84,7 +84,7 @@ However, `luet` supports an extended syntax that allows to define packages with
 
 ### The extended syntax
 
-A [package definition](/docs/docs/concepts/packages/specfile) is composed of a `build.yaml` and a sibiling `definition.yaml`.
+A [package definition](/docs/concepts/packages/specfile) is composed of a `build.yaml` and a sibiling `definition.yaml`.
 
 In the following example, we are creating a dummy package (`bar/foo`). Which ships one file only, `/foo`
 

docs/content/en/docs/Concepts/Overview/constraints.md

@@ -8,7 +8,7 @@ description: >
 
 Under the hood, Luet uses boolean satisfiability problem ([SAT](https://en.wikipedia.org/wiki/Boolean_satisfiability_problem))  [reinforcement learning](https://en.wikipedia.org/wiki/Reinforcement_learning) techniques to solve package constraints.
 
-Luet allows you to specify 3 types of set of contraints on a [package](/docs/docs/concepts/packages/) definition:
+Luet allows you to specify 3 types of set of contraints on a [package](/docs/concepts/packages/) definition:
 
 - Requires
 - Conflicts
@@ -18,7 +18,7 @@ The package definition in your tree definition, along with its Requires and Conf
 
 ## Requires and Conflicts
 
-A list of requires and conflicts, composed of one or more [packages](/docs/docs/concepts/packages/), becomes a SAT formula. The formula is then given to the SAT solver to compute a finite state set of packages which must be installed in the system in order to met the requirements.
+A list of requires and conflicts, composed of one or more [packages](/docs/concepts/packages/), becomes a SAT formula. The formula is then given to the SAT solver to compute a finite state set of packages which must be installed in the system in order to met the requirements.
 
 As Luet allows to express constraints with selectors ( e.g. `A depends on >=B-1.0`) it generates additional constraints to guarantee that at least one package and at most one is picked as dependency (*ALO* and *AMO*).
 

docs/content/en/docs/Concepts/Packages/_index.md

@@ -61,7 +61,7 @@ By a combination of keywords in `build.yaml`, you end up with categories of pack
 - Package layers
 - Package with includes
 
-Check the [Specfile concept](/docs/docs/concepts/packages/specfile) page for a full overview of the available keywords in the Luet specfile format.
+Check the [Specfile concept](/docs/concepts/packages/specfile) page for a full overview of the available keywords in the Luet specfile format.
 
 ### Seed packages
 

docs/content/en/docs/Concepts/Packages/collections.md

@@ -24,7 +24,7 @@ Luet during the build phase, will treat packages of a collection individually. A
 
 ## Templating
 
-[The templating mechanism](/docs/docs/concepts/packages/templates) can be used in collections as well, and each stanza in `packages` is used to interpolate each single package. 
+[The templating mechanism](/docs/concepts/packages/templates) can be used in collections as well, and each stanza in `packages` is used to interpolate each single package. 
 
 ## Examples
 

docs/content/en/docs/Concepts/Packages/specfile.md

@@ -9,7 +9,7 @@ description: >
 
 # Specfiles
 
-Luet [packages](/docs/docs/concepts/packages/) are defined by specfiles. Specfiles define the runtime and builtime requirements of a package.  There is an hard distinction between runtime and buildtime. A spec is composed at least by the runtime (`definition.yaml` or a `collection.yaml`) and the buildtime specification (`build.yaml`).
+Luet [packages](/docs/concepts/packages/) are defined by specfiles. Specfiles define the runtime and builtime requirements of a package.  There is an hard distinction between runtime and buildtime. A spec is composed at least by the runtime (`definition.yaml` or a `collection.yaml`) and the buildtime specification (`build.yaml`).
 
 Luet identifies the package definition by looking at directories that contains a `build.yaml` and a `definition.yaml` (or `collection.yaml`) files. A Luet tree is merely a composition of directories that follows this convention. There is no constriction on either folder naming or hierarchy.
 
@@ -181,7 +181,7 @@ conflicts:
   version: "1.0"
 ```
 
-See [Package concepts](/docs/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
+See [Package concepts](/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
 
 ### `copy`
 
@@ -309,7 +309,7 @@ join:
   version: "1.0"
 ```
 
-See [Package concepts](/docs/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
+See [Package concepts](/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
 
 #### Examples
 
@@ -357,7 +357,7 @@ requires:
   version: "1.0"
 ```
 
-See [Package concepts](/docs/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
+See [Package concepts](/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
 
 ### `requires_final_images`
 
@@ -428,7 +428,7 @@ Every subpackage stanza supports `excludes` and `includes` to selectively exclud
 
 Note, subpackages support is available for collection, standard packages and templated packages.
 
-See [Package concepts](/docs/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
+See [Package concepts](/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
 
 ## Rutime specs
 
@@ -485,7 +485,7 @@ packages:
 ...
 ```
 
-All the fields (also the ones which are not part of the spec) in the `definition.yaml` file are available as templating values when rendering the `build.yaml` file. When running [finalizers](/docs/docs/concepts/packages/specfile/#finalizers) instead only the fields belonging to the specs are available.
+All the fields (also the ones which are not part of the spec) in the `definition.yaml` file are available as templating values when rendering the `build.yaml` file. When running [finalizers](/docs/concepts/packages/specfile/#finalizers) instead only the fields belonging to the specs are available.
 
 ### Keywords
 
@@ -525,7 +525,7 @@ conflicts:
   version: "1.0"
 ```
 
-See [Package concepts](/docs/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
+See [Package concepts](/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
 
 ### `description`
 
@@ -592,7 +592,7 @@ conflicts:
   version: "1.0"
 ```
 
-See [Package concepts](/docs/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
+See [Package concepts](/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
 
 ### `requires`
 
@@ -611,7 +611,7 @@ requires:
   version: "1.0"
 ```
 
-See [Package concepts](/docs/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
+See [Package concepts](/docs/concepts/packages) for more information on how to represent a package in a Luet tree.
 
 ### `uri`
 

docs/content/en/docs/Resources/arm.md

@@ -63,4 +63,4 @@ At the end of the process, a file `luet_os.img`, ready to be flashed to an SD ca
 
 ## Add packages
 
-In order to build and add [packages](/docs/docs/concepts/packages/) to the exiting repository, simply add or edit the [specfiles](/docs/docs/concepts/specfile) under the `distro` folder. When doing ```make rebuild-all``` the packages will be automatically compiled and made available to the local repository.
+In order to build and add [packages](/docs/concepts/packages/) to the exiting repository, simply add or edit the [specfiles](/docs/concepts/packages/specfile) under the `distro` folder. When doing ```make rebuild-all``` the packages will be automatically compiled and made available to the local repository.

docs/content/en/docs/Resources/building.md

@@ -8,7 +8,7 @@ description: >
 
 ## Simple package build
 
-Creating and building a simple [package](/docs/docs/concepts/packages/):
+Creating and building a simple [package](/docs/concepts/packages/):
 
 ```
 $> mkdir package
@@ -40,7 +40,7 @@ $> luet build --all
 
 ### Build packages
 
-In order to build a specific version, a full [package](/docs/docs/concepts/packages/) definition (triple of `category`, `name` and `version`) has to be specified.
+In order to build a specific version, a full [package](/docs/concepts/packages/) definition (triple of `category`, `name` and `version`) has to be specified.
 In this example we will also enable package compression (gzip).
 
 ```

docs/content/en/docs/_index.md

@@ -11,8 +11,8 @@ menu:
 
 Luet is a Package Manager based on containers. It provides an abstraction layer over container specfile format, enhancing the image resolution process of open container inititative ([OCI](https://en.wikipedia.org/wiki/Open_Container_Initiative)) runtimes with boolean satisfiability problem ([SAT](https://en.wikipedia.org/wiki/Boolean_satisfiability_problem)) solving techniques.
 
-Luet can be used to build [packages](/docs/docs/concepts/packages/), container images, as well as to manage and distribute installations of derived [packages](/docs/docs/concepts/packages/) locally.
+Luet can be used to build [packages](/docs/concepts/packages/), container images, as well as to manage and distribute installations of derived [packages](/docs/concepts/packages/) locally.
 
-Allows to apply semver [constraints](/docs/docs/concepts/overview/constraints/) to Image dependencies, treating it as a classical [CSP](https://en.wikipedia.org/wiki/Constraint_satisfaction_problem).
+Allows to apply semver [constraints](/docs/concepts/overview/constraints/) to Image dependencies, treating it as a classical [CSP](https://en.wikipedia.org/wiki/Constraint_satisfaction_problem).
 
 <script id="asciicast-388348" src="https://asciinema.org/a/388348.js" data-autoplay="true" data-size="small" data-cols="90" data-rows="30" async></script>