⚙️ Add ability to build from Dockerfiles directly

docs/content/en/_index.html

@@ -22,7 +22,7 @@ linkTitle = "luetdocs"
 
 {{% blocks/lead color="primary" %}}
 
-Luet uses Container technologies ( Docker, img ) to build packages.
+Luet uses Container runtimes to build packages in a reproducible manner.
 It provides an abstraction over the Dockerfile format introducing relation and versioning of images.
 
 {{% /blocks/lead %}}
@@ -42,8 +42,8 @@ New users are always welcome, and have fun!
 {{% /blocks/feature %}}
 
 
-{{% blocks/feature icon="fa-terminal" title="Container-based" %}}
-Use container abstraction to define your package repositories
+{{% blocks/feature icon="fa-terminal" title="Container-based, reproducible builds" %}}
+Use container abstraction to define package repositories. Intermediate build images are pushed along to guarantee reproducible builds.
 {{% /blocks/feature %}}
 
 {{< /blocks/section >}}

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

@@ -15,7 +15,7 @@ Luet is written entirely in Go and comes as a single static binary. This has a f
 - Package manager has no dependencies on the packages that it installs. There is no chance of breaking the package manager by installing a conflicting package, or uninstalling one.
 - Portable - it can run on any architecture
 
-Luet brings the containers ecosystem to standard software package management and delivery. It is fully built around the container concept, and leverages the huge catalog already present in the wild. It lets you use Docker images from [Docker Hub](https://hub.docker.com/), or from private registries to build packages, and helps you to redistribute them.
+Luet brings the containers ecosystem to standard software package management and delivery. It is fully built around the container concept, and leverages the huge catalog already present in the wild. It lets you use container images from [Docker Hub](https://hub.docker.com/), or from private registries to build packages, and helps you to redistribute them.
 
 Systems that are using luet as a package manager can consume Luet repositories with only luet itself. No dependency is required by the Package manager, giving you the full control on what you install or not in the system. It can be used to generate *Linux from Scratch* distributions,  also to build Docker images, or to simply build standalone packages that you might want to redistribute.
 

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

@@ -32,12 +32,18 @@ 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).
+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.
 
 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.
 
+## Reproducible builds
+
+Pinning a container build is not easy - there are always so many moving pieces, and sometimes just set `FROM` an image tag might not be enough.
+
+Luet while building a package generates intermediate images that are stored and can be optionally pushed in a registry. Those images can be re-used by Luet if building again the same tree to guarantuee highly reproducible builds.
+
 ## Environmental variables
 
 Luet builds passes its environment variable at the engine which is called during build, so for example the environment variable `DOCKER_HOST` or `DOCKER_BUILDKIT` can be setted.
@@ -100,6 +106,25 @@ $> luet build --all
 
 Luet "trees" are just a group of specfiles, in the above example, our tree was the current directory. You can also specify a directory with the `--tree` option. Luet doesn't enforce any tree layout, so they can be nested at any level. The only rule of thumb is that a `build.yaml` file needs to have either a `definition.yaml` or a `collection.yaml` file next to it.
 
+## Dockerfile example
+
+Luet can seamlessly build packages also from Dockerfiles, consider the following example, that will generate a `curl` package from an `alpine` image:
+
+```bash
+$> # put yourself in some workdir
+
+$~/workdir> mkdir curl
+
+$~/workdir> cat <<EOF > curl/Dockerfile
+FROM alpine
+apk add curl
+EOF
+
+$~/workdir> luet build --all
+
+```
+
+
 ## Nesting dependencies
 
 In the example above we have created a package from a `delta`. Luet by default creates packages by analyzing the differences between the generated containers, and extracts the differences as archive, the resulting files then are compressed and can be consumed later on by `luet install`.