mirror of
https://github.com/mudler/luet.git
synced 2025-05-11 18:04:30 +00:00
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>
This commit is contained in:
parent
2513760b00
commit
5d37518888
docs/content/en/docs
@ -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.
|
||||
|
@ -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`
|
||||
|
||||
|
@ -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*).
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -24,10 +24,10 @@ 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
|
||||
|
||||
- https://github.com/mocaccinoOS/mocaccino-musl-universe/tree/master/multi-arch/packages/entities
|
||||
- https://github.com/mocaccinoOS/portage-tree/tree/master/multi-arch/packages/groups
|
||||
- https://github.com/mocaccinoOS/mocaccino-musl-universe/tree/master/multi-arch/packages/X
|
||||
- https://github.com/mocaccinoOS/mocaccino-musl-universe/tree/master/multi-arch/packages/X
|
||||
|
@ -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`
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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).
|
||||
|
||||
```
|
||||
|
@ -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>
|
||||
|
Loading…
Reference in New Issue
Block a user