#1249 Add documentation that defines libsolv terms and how they relate to MBS
Merged 4 years ago by mprahl. Opened 4 years ago by mprahl.

@@ -0,0 +1,40 @@ 

+ How libsolv Works in MBS

+ ========================

+ 

+ Libsolv Terms

+ -------------

+ 

+ - **Pool** - the main object that represents the libsolv context that all "solvables" get added to

+   it.

+ - **Dep** - an object used for dependency resolution metadata on a string. For example, a ``Dep``

+   object might be "platform:el8" (module name and stream), or it might just be a version of a

+   module, such as "80000". With these ``Dep`` objects, we can use operators, such as ``REL_EQ``,

+   ``REL_OR``, and ``REL_GT`` to define the relation between ``Dep`` objects. For example, the

+   "platform:el8" ``Dep`` object would have a ``REL_EQ`` relationship with the "80000" ``Dep``

+   object. After creating this relationship, a new ``Dep`` object is returned, with that

+   relationship. That ``Dep`` object can then be used in the ``add_deparray`` method, which provides

+   a relationship from this ``Dep`` object to a solvable.

+ - **Solvable** - an installable artifact with properties such as name, version, release, and arch

+   that is created in a repo in the pool. Usually, a solvable represents an RPM, but in the case of

+   MBS, it represents a module.

+ 

+   - **Requires** - the ``Dep`` objects that this solvable requires to be available in the repo when

+     the solvable is installed.

+   - **Provides** - the ``Dep`` objects that this solvable provides. For example,

+     "platform:el8:0:c1" (NSVC), would also provide "platform:el8" and "platform:el8 = 0"

+     (``REL_EQ`` relationship), this way a solvable can require ``platform:el8`` and not the whole

+     NSVC.

+   - **Conflicts** - the ``Dep`` objects that represent a solvable that cannot be installed when this

+     solvable is installed. For example, two modules of the same name but different stream, cannot be

+     installed at the same time, so a "foo:bar1" conflicts with "foo:bar2" and vice-versa.

+ - **Repo** - a collection of solvables.

+ - **Job** - what to do with the solvables in the pool. In MBS, this involves stating the solvable we

+   want to install (the module being built), and then the solvables that are preferred in the

+   solution, which override the default behavior of libsolv. For example, if the "platform:f28" and

+   "platform:f29" solvables are both in the pool (due to Module Stream Expansion), MBS will create

+   two sets of jobs, the first which favors "platform:f28", and the second which favors

+   "platform:f29". This way, if possible, the dependencies are determined for both platforms.

+ - **Solver** - executes the jobs, and finds the best solution for the given jobs based on the

+   solvables in the pool.

+ - **Transaction** - this describes the solution from the solver execution. In MBS, this is always

+   about installing the solvable that represents the module being built.

no initial comment

@ignatenkobrain could you please review this and help us correct any mistakes? @jkaluza and I are working on documenting how dependency resolution works in MBS and this is the first step.

This looks ok, except that it doesn't help in any way how depsolving works..

Lgtm anyway.

@ignatenkobrain we have more documentation coming. Thanks for the review.

Pull-Request has been merged by mprahl

4 years ago