A new keyword `join` is introduced to generate the parent image. It
takes precedence over a `requires` or a `image` already defined in a
spec.
It will generate all the artifacts from the packages listed and join
them in a single image which will be used as parent for the package
build process.
This is a change which invalidates priorly generated hashes.
Fixes#173
- Interpolates values from the repositories compilespec if present
- Automatically merge cache images coming from specified repository when
necessary
Fixes#194
Also make possible to retrieve the artifact when searching for matches
between repositories list. This made possible to show the package list
when calling `luet search`.
When we cycle, we don't necessarly have all the packages into the DB
yet.
With this change, luet annotates the reverse dependency without any version, and we try to
update revdeps table when new items gets added, by checking the version
required in the selector.
Thanks to @joostruis for noticing the issue
Collections, similarly to packages, have a `build.yaml` and
a `finalize.yaml` that are templated for each package.
They have a `collection.yaml` containing a list of
packages that are part of the tree.
With this change the solver during install now considers only the part
of the tree which is required to calculate the solution, it doesn't
consider anymore World() as the search space.
The search space now is narrowed down to the packages that related to
the one which we are considering.
In this subset of changes we are also optimizing the Parallel solver
avoiding an useless loop.
This change boost overall performance on large datasets which don't
necessarly have relations touching the whole tree.
The parallel solver made the issue more visible, the constraints needed
to be less relaxed and needed to be exclusive so our candidate is looked
up at it first
Annotate the package build time when compiling, and use that from the
client to force upgrade of packages that changed the artifact, but
didn't changed any version.
The client can trigger this behavior with `luet upgrade --sync`
This allows to have an unique identifier for the builder image id against
different depgraphs combinations. The package fingerprint is not enough,
as an atom could have a difference deptree depending on the requires
constraints.
TODO: Don't use the full image name, but only the hash as a salt
(currently the salt contains ALSO a reference of the image-repository,
as such it doesn't allow to port a tree in a different docker registry)
