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)
* cmd/search: Add support for search of the packages
with a specific label.
* review Search method of Repositories for permit
different search modes.
* labels are k/v attributes and could be matched
through label key (with HasLabel method) or through
regex that use "$key" + "=" + "$value"
