mirror of
https://github.com/mudler/luet.git
synced 2025-06-27 15:59:22 +00:00
378 lines
43 KiB
XML
378 lines
43 KiB
XML
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
|
||
<channel>
|
||
<title>Luet – Overview</title>
|
||
<link>https://luet.io/docs/concepts/overview/</link>
|
||
<description>Recent content in Overview on Luet</description>
|
||
<generator>Hugo -- gohugo.io</generator>
|
||
|
||
<atom:link href="https://luet.io/docs/concepts/overview/index.xml" rel="self" type="application/rss+xml" />
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<item>
|
||
<title>Docs: Building packages</title>
|
||
<link>https://luet.io/docs/concepts/overview/build_packages/</link>
|
||
<pubDate>Thu, 05 Jan 2017 00:00:00 +0000</pubDate>
|
||
|
||
<guid>https://luet.io/docs/concepts/overview/build_packages/</guid>
|
||
<description>
|
||
|
||
|
||
<h2 id="prerequisistes">Prerequisistes</h2>
|
||
<p>Luet currently supports <a href="https://www.docker.com/">Docker</a> and <a href="https://github.com/genuinetools/img">Img</a> as backends to build packages. Both of them can be used and switched in runtime with the <code>--backend</code> option, so either one of them must be present in the host system.</p>
|
||
<h3 id="docker">Docker</h3>
|
||
<p>Docker is the (less) experimental Luet engine supported. Be sure to have Docker installed and the daemon running. The user running <code>luet</code> commands needs the corresponding permissions to run the <code>docker</code> executable, and to connect to a <code>docker</code> daemon. The only feature needed by the daemon is the ability to build images, so it fully supports remote daemon as well (this can be specified with the <code>DOCKER_HOST</code> environment variable, that is respected by <code>luet</code>)</p>
|
||
<h3 id="img">Img</h3>
|
||
<p>Luet supports <a href="https://github.com/genuinetools/img">Img</a>. To use it, simply install it in your system, and while running <code>luet build</code>, you can switch the backend by providing it as a parameter: <code>luet build --backend img</code>. For small packages it is particularly powerful, as it doesn&rsquo;t require any docker daemon running in the host.</p>
|
||
<h3 id="building-packages-on-kubernetes">Building packages on Kubernetes</h3>
|
||
<p>Luet and img can be used together to orchestrate package builds also on kubernetes. There is available an experimental <a href="https://github.com/mudler/luet-k8s">Kubernetes CRD for Luet</a> which allows to build packages seamelessly in Kubernetes and push package artifacts to an S3 Compatible object storage (e.g. Minio).</p>
|
||
<h2 id="building-packages">Building packages</h2>
|
||
<p><img src="https://luet.io/docs/tree.jpg" alt="Build packages"></p>
|
||
<p>Luet provides an abstraction layer on top of the container image layer to make the package a first class construct. A package definition and all its dependencies are translated by Luet to Dockerfiles which can then be built anywhere that docker runs.</p>
|
||
<p>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.</p>
|
||
<p>Building a package with Luet requires only a <a href="https://luet.io/docs/docs/concepts/packages/specfile">definition</a>. This definition can be self-contained and be only composed of one <a href="https://luet.io/docs/docs/concepts/packages/specfile">specfile</a>, or a group of them, forming a Luet tree. For more complex use-cases, see <a href="https://luet.io/docs/docs/concepts/packages/collections">collections</a>.</p>
|
||
<p>Run <code>luet build --help</code> to get more help for each parameter.</p>
|
||
<p>Build accepts a list of packages to build, which syntax is in the <code>category/name-version</code> notation. See also <a href="https://luet.io/docs/docs/concepts/packages/specfile/#refering-to-packages-from-the-cli">specfile documentation page</a> to see how to express packages from the CLI.</p>
|
||
<h2 id="environmental-variables">Environmental variables</h2>
|
||
<p>Luet builds passes its environment variable at the engine which is called during build, so for example the environment variable <code>DOCKER_HOST</code> or <code>DOCKER_BUILDKIT</code> can be setted.</p>
|
||
<p>Every argument from the CLI can be setted via environment variable too with a <code>LUET_</code> prefix, for instance the flag <code>--clean</code>, can be setted via environment with <code>LUET_CLEAN</code>, <code>--privileged</code> can be enabled with <code>LUET_PRIVILEGED</code> and so on.</p>
|
||
<h2 id="supported-compression-format">Supported compression format</h2>
|
||
<p>At the moment, <code>luet</code> can compress packages and tree with <code>zstd</code> and <code>gzip</code>. For example:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">luet build --compression zstd ...
|
||
</code></pre></div><p>Will output package compressed in the zstd format.</p>
|
||
<p>See the <code>--help</code> of <code>create-repo</code> and <code>build</code> to learn all the available options.</p>
|
||
<h2 id="example">Example</h2>
|
||
<p>A <a href="https://luet.io/docs/docs/concepts/packages/specfile">package definition</a> is composed of a <code>build.yaml</code> and a sibiling <code>definition.yaml</code>.</p>
|
||
<p>In the following example, we are creating a dummy package (<code>bar/foo</code>). Which ships one file only, <code>/foo</code></p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">$&gt; <span style="color:#8f5902;font-style:italic"># put yourself in some workdir</span>
|
||
|
||
$~/workdir&gt; mkdir package
|
||
|
||
$~/workdir&gt; cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; package/build.yaml
|
||
</span><span style="color:#4e9a06">image: busybox
|
||
</span><span style="color:#4e9a06">steps:
|
||
</span><span style="color:#4e9a06">- echo &#34;foo=bar&#34; &gt; /foo
|
||
</span><span style="color:#4e9a06">EOF</span>
|
||
|
||
$~/workdir&gt; cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; package/definition.yaml
|
||
</span><span style="color:#4e9a06">name: &#34;foo&#34;
|
||
</span><span style="color:#4e9a06">version: &#34;0.1&#34;
|
||
</span><span style="color:#4e9a06">category: &#34;bar&#34;
|
||
</span><span style="color:#4e9a06">EOF</span>
|
||
|
||
</code></pre></div><p>To build it, simply run <code>luet build bar/foo</code> or <code>luet build --all</code> to build all the packages in the current directory:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">$&gt; luet build --all
|
||
|
||
📦 Selecting foo 0.1
|
||
📦 Compiling foo version 0.1 .... ☕
|
||
🐋 Downloading image luet/cache-foo-bar-0.1-builder
|
||
🐋 Downloading image luet/cache-foo-bar-0.1
|
||
📦 foo Generating 🐋 definition <span style="color:#204a87;font-weight:bold">for</span> builder image from busybox
|
||
🐋 Building image luet/cache-foo-bar-0.1-builder
|
||
🐋 Building image luet/cache-foo-bar-0.1-builder <span style="color:#204a87;font-weight:bold">done</span>
|
||
Sending build context to Docker daemon 4.096kB
|
||
...
|
||
|
||
</code></pre></div><p>Luet &ldquo;trees&rdquo; are just a group of specfiles, in the above example, our tree was the current directory. You can also specify a directory with the <code>--tree</code> option. Luet doesn&rsquo;t enforce any tree layout, so they can be nested at any level. The only rule of thumb is that a <code>build.yaml</code> file needs to have either a <code>definition.yaml</code> or a <code>collection.yaml</code> file next to it.</p>
|
||
<h2 id="nesting-dependencies">Nesting dependencies</h2>
|
||
<p>In the example above we have created a package from a <code>delta</code>. 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 <code>luet install</code>.</p>
|
||
<p>Luet can create packages from different <a href="https://luet.io/docs/docs/concepts/packages/specfile/#building-strategies">building strategies</a>: by delta, by taking a whole container content, or by considering a single directory in the build container.</p>
|
||
<p>Besides that, <a href="https://luet.io/docs/docs/concepts/packages/specfile/#build-time-dependencies">a package can reference a strict dependency on others</a>.</p>
|
||
<h3 id="example-1">Example</h3>
|
||
<p>Let&rsquo;s extend the above example with two packages which depends on it during the build phase.</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">
|
||
$~/workdir&gt; mkdir package2
|
||
|
||
$~/workdir&gt; cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; package2/build.yaml
|
||
</span><span style="color:#4e9a06">requires:
|
||
</span><span style="color:#4e9a06">- name: &#34;foo&#34;
|
||
</span><span style="color:#4e9a06"> category: &#34;bar&#34;
|
||
</span><span style="color:#4e9a06"> version: &#34;&gt;=0&#34;
|
||
</span><span style="color:#4e9a06">
|
||
</span><span style="color:#4e9a06">steps:
|
||
</span><span style="color:#4e9a06">- source /foo &amp;&amp; echo &#34;$foo&#34; &gt; /bar
|
||
</span><span style="color:#4e9a06">EOF</span>
|
||
|
||
$~/workdir&gt; cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; package2/definition.yaml
|
||
</span><span style="color:#4e9a06">name: &#34;ineedfoo&#34;
|
||
</span><span style="color:#4e9a06">version: &#34;0.1&#34;
|
||
</span><span style="color:#4e9a06">category: &#34;bar&#34;
|
||
</span><span style="color:#4e9a06">EOF</span>
|
||
|
||
|
||
$~/workdir&gt; mkdir package3
|
||
|
||
$~/workdir&gt; cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; package3/build.yaml
|
||
</span><span style="color:#4e9a06">requires:
|
||
</span><span style="color:#4e9a06">- name: &#34;foo&#34;
|
||
</span><span style="color:#4e9a06"> category: &#34;bar&#34;
|
||
</span><span style="color:#4e9a06"> version: &#34;&gt;=0&#34;
|
||
</span><span style="color:#4e9a06">- name: &#34;ineedfoo&#34;
|
||
</span><span style="color:#4e9a06"> category: &#34;bar&#34;
|
||
</span><span style="color:#4e9a06"> version: &#34;&gt;=0&#34;
|
||
</span><span style="color:#4e9a06">
|
||
</span><span style="color:#4e9a06">steps:
|
||
</span><span style="color:#4e9a06">- source /foo &amp;&amp; echo &#34;$foo&#34; &gt; /ineedboth
|
||
</span><span style="color:#4e9a06">- cat /bar &gt; /bar
|
||
</span><span style="color:#4e9a06">
|
||
</span><span style="color:#4e9a06">EOF</span>
|
||
|
||
$~/workdir&gt; cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; package3/definition.yaml
|
||
</span><span style="color:#4e9a06">name: &#34;ineedfooandbar&#34;
|
||
</span><span style="color:#4e9a06">version: &#34;0.1&#34;
|
||
</span><span style="color:#4e9a06">category: &#34;bar&#34;
|
||
</span><span style="color:#4e9a06">EOF</span>
|
||
|
||
</code></pre></div><p>To build, run again:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">$&gt; luet build --all
|
||
</code></pre></div><p>As we can see, now Luet generated 3 packages, <code>bar/foo</code>, <code>bar/ineedfoo</code> and <code>bar/ineedfooandbar</code>. They aren&rsquo;t doing anything special than just shipping text files, this is an illustrative example on how build requirements can be combined to form new packages:</p>
|
||
<p><code>bar/ineedfooandbar</code> depends on both <code>bar/ineedfoo</code> and <code>bar/foo</code> during build-time, while <code>bar/foo</code> uses a docker image as a build base.</p>
|
||
<p>See the <a href="https://luet.io/docs/docs/concepts/packages/specfile/#building-strategies">package definition documentation page</a> for more details on how to instruct the Luet compiler to build packages with different strategies.</p>
|
||
<h2 id="caching-docker-images">Caching docker images</h2>
|
||
<p>Luet can push and pull the docker images that are being generated during the build process. A tree is represented by a single docker image, and each package can have one or more tags attached to it.</p>
|
||
<p>To push automatically docker images that are built, use the <code>--push</code> option, to pull, use the <code>--pull</code> option. An image repository can be specified with <code>--image-repository</code> flag, and can include also the remote registries where the images are pushed to.</p>
|
||
<p>Luet doesn&rsquo;t handle login to registries, so that has to be handled separately with <code>docker login</code> or <code>img login</code> before the build process starts.</p>
|
||
<h3 id="build-faster">Build faster</h3>
|
||
<p>When packages are cached, for iterating locally it&rsquo;s particularly useful to jump straight to the image that you want to build. You can use <code>--only-target-package</code> to jump directly to the image you are interested in. Luet will take care of checking if the images are present in the remote registry, and would build them if any of those are missing.</p>
|
||
<h2 id="notes">Notes</h2>
|
||
<ul>
|
||
<li>All the files which are next to a <code>build.yaml</code> are copied in the container which is running your build, so they are always accessible during build time.</li>
|
||
<li>If you notice errors about disk space, mind to set the <code>TMPDIR</code> env variable to a different folder. By default luet respects the O.S. default (which in the majority of system is <code>/tmp</code>).</li>
|
||
</ul>
|
||
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Docs: Creating Luet repositories</title>
|
||
<link>https://luet.io/docs/concepts/overview/repositories/</link>
|
||
<pubDate>Thu, 05 Jan 2017 00:00:00 +0000</pubDate>
|
||
|
||
<guid>https://luet.io/docs/concepts/overview/repositories/</guid>
|
||
<description>
|
||
|
||
|
||
<p>After a set of packages has been built, a repository must be created in order to make them accessible by Luet clients. A Repository can be served either local files or via http(s) (at the moment of writing). Luet, by default, supports multiple-repositories with priorities.</p>
|
||
<h2 id="repository-fields">Repository fields</h2>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-yaml" data-lang="yaml"><span style="color:#204a87;font-weight:bold">name</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#4e9a06">&#34;...&#34;</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">description</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#4e9a06">&#34;...&#34;</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">type</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#4e9a06">&#34;docker&#34;</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">cached</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">true</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">enabled</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">true</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">arch</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#4e9a06">&#34;amd64&#34;</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">priority</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#0000cf;font-weight:bold">3</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">urls</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"> </span>- <span style="color:#4e9a06">&#34;...&#34;</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span></code></pre></div><p>Repositories have the following fields, notably:</p>
|
||
<ul>
|
||
<li><code>name</code>: Repository name</li>
|
||
<li><code>description</code>: Repository description</li>
|
||
<li><code>cached</code>: Enable/disable repository cache</li>
|
||
<li><code>enable</code>: Enable/disables the repository</li>
|
||
<li><code>urls</code>: A List of urls where the repository is hosted from</li>
|
||
<li><code>type</code>: Repository type ( <code>docker</code>, <code>disk</code>, <code>http</code> are currently supported )</li>
|
||
<li><code>arch</code>: (optional) Denotes the arch repository. If present, it will enable the repository automatically if the corresponding arch is matching with the host running <code>luet</code>. <code>enable: true</code> would override this behavior</li>
|
||
<li><code>reference</code>: (optional) A reference to a repository index file to use to retrieve the repository metadata instead of latest. This can be used to point to a different or an older repository index to act as a &ldquo;wayback machine&rdquo;. The client will consume the repository state from that snapshot instead of latest.</li>
|
||
</ul>
|
||
|
||
|
||
<div class="alert alert-primary" role="alert">
|
||
<h4 class="alert-heading">Note</h4>
|
||
|
||
The <code>reference</code> field has to be a valid tag. For example, if a repository is a docker type, browse the image tags. The repository index snapshots are prefixed with a timestamp, and ending in <code>repository.yaml</code>. For example <code> 20211027153653-repository.yaml</code>
|
||
|
||
</div>
|
||
|
||
<h2 id="create-a-repository">Create a repository</h2>
|
||
<p>After issuing a <code>luet build</code>, the built packages are present in the output build directory. The <code>create-repo</code> step is needed to generate a portable tree, which is read by the clients, and a <code>repository.yaml</code> which contains the repository metadata.</p>
|
||
<p>Note that the output of <code>create-repo</code> is <em>additive</em> so it integrates with the current build content. The repository is composed by the packages generated by the <code>build</code> command (or <code>pack</code>) and the <code>create-repo</code> generated metadata.</p>
|
||
<h3 id="flags">Flags</h3>
|
||
<p>Some of the relevant flags for <code>create-repo</code> are:</p>
|
||
<ul>
|
||
<li><strong>&ndash;descr</strong>: Repository description</li>
|
||
<li><strong>&ndash;name</strong>: Repository name</li>
|
||
<li><strong>&ndash;output</strong>: Metadata output folder (while a different path can be specified, it&rsquo;s prefered to output the metadata files directly to the package directory).This most of the time matches the packages path for convenience.</li>
|
||
<li><strong>&ndash;packages</strong>: Directory where built packages are stored. This most of the time is also the output path.</li>
|
||
<li><strong>&ndash;reset-revision</strong>: Reset the repository revision number</li>
|
||
<li><strong>&ndash;tree-path</strong>: Specify a custom name for the tree path. (Defaults to tree.tar)</li>
|
||
<li><strong>&ndash;tree-compression</strong>: Specify a compression algorithm for the tree. (Available: gzip, Defaults: none)</li>
|
||
<li><strong>&ndash;tree</strong>: Path of the tree which was used to generate the packages and holds package metadatas</li>
|
||
<li><strong>&ndash;type</strong>: Repository type (http/local). It is just descriptive, the clients will be able to consume the repo in whatsoever way it is served.</li>
|
||
<li><strong>&ndash;urls</strong>: List of URIS where the repository is available</li>
|
||
</ul>
|
||
<p>See <code>luet create-repo --help</code> for a full description.</p>
|
||
<h2 id="example">Example</h2>
|
||
<p>Build a package and generate the repository metadata:</p>
|
||
<pre tabindex="0"><code>$&gt; mkdir package
|
||
|
||
$&gt; cat &lt;&lt;EOF &gt; package/build.yaml
|
||
image: busybox
|
||
steps:
|
||
- echo &quot;foo&quot; &gt; /foo
|
||
EOF
|
||
|
||
$&gt; cat &lt;&lt;EOF &gt; package/definition.yaml
|
||
name: &quot;foo&quot;
|
||
version: &quot;0.1&quot;
|
||
category: &quot;bar&quot; # optional!
|
||
EOF
|
||
|
||
$&gt; luet build --all --destination $PWD/out/ --tree $PWD/package
|
||
|
||
📦 Selecting foo 0.1
|
||
📦 Compiling foo version 0.1 .... ☕
|
||
🐋 Downloading image luet/cache-foo-bar-0.1-builder
|
||
🐋 Downloading image luet/cache-foo-bar-0.1
|
||
📦 foo Generating 🐋 definition for builder image from busybox
|
||
🐋 Building image luet/cache-foo-bar-0.1-builder
|
||
🐋 Building image luet/cache-foo-bar-0.1-builder done
|
||
Sending build context to Docker daemon 4.096kB
|
||
...
|
||
|
||
$&gt; luet create-repo --name &quot;test&quot; --output $PWD/out --packages $PWD/out --tree $PWD/package
|
||
For repository test creating revision 1 and last update 1580641614...
|
||
|
||
$&gt; ls out
|
||
foo-bar-0.1-builder.image.tar foo-bar-0.1.image.tar foo-bar-0.1.metadata.yaml foo-bar-0.1.package.tar repository.yaml tree.tar
|
||
|
||
</code></pre><h3 id="repositories-type">Repositories type</h3>
|
||
<p>There are 3 types of repositories supported by luet: <code>disk</code>, <code>http</code>, <code>docker</code>.</p>
|
||
<h4 id="disk"><code>disk</code></h4>
|
||
<p>It is a repository which is merely a local folder in your system. When creating a repository and specifying <code>--output</code>, <code>luet</code> expects a local path to the system where to store the generated metadata.</p>
|
||
<h4 id="http"><code>http</code></h4>
|
||
<p>It is a repository type which is hosted behind a webserver. When creating a repository and specifying <code>--output</code>, <code>luet</code> expects a local path to the system where to store the generated metadata, similarly to the <code>disk</code> repository type. Luet is not handling any file upload. The <code>http</code> repository type gains meaning when being used from the client, where the repository source must be specified</p>
|
||
<h4 id="docker"><code>docker</code></h4>
|
||
<p>When specifying the <code>docker</code> repository type, <code>luet</code> will generate final images from the build results and upload them to the docker reference specified with <code>--output</code>. The images contains the artifact output from the build result, and they are tagged accordingly to their package name. A single image reference needs to be passed, all the packages will be pushed in a single image but with different tags.</p>
|
||
<p>The login to the container registry is not handled, the daemon needs to have already proper permissions to push the image to the destination.</p>
|
||
<h2 id="repositories-snapshots">Repositories snapshots</h2>
|
||
<p>Luet automatically will create repository index snapshots. This allows clients to point to specific references of repositories besides the latest package set published.</p>
|
||
<p><code>luet create-repo</code> optionally takes a <code>--snapshot-id</code> argument to define the snapshot name, otherwise it defaults to the unix date timestamp.</p>
|
||
<p>Combined with <code>--push-images</code> with a container repository type, it automatically tags and pushes snapshots images too.</p>
|
||
<h3 id="consuming-repository-snapshots">Consuming repository snapshots</h3>
|
||
<p>A client can define a repository, with an optional <code>reference</code> keyword:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-yaml" data-lang="yaml"><span style="color:#204a87;font-weight:bold">name</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#4e9a06">&#34;...&#34;</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">description</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#4e9a06">&#34;...&#34;</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">type</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#4e9a06">&#34;docker&#34;</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">priority</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#0000cf;font-weight:bold">3</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">reference</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#0000cf;font-weight:bold">20220204175357</span>-<span style="color:#000">repository.yaml</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">urls</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span><span style="color:#f8f8f8;text-decoration:underline"> </span>- <span style="color:#4e9a06">&#34;...&#34;</span><span style="color:#f8f8f8;text-decoration:underline">
|
||
</span></code></pre></div><h2 id="notes">Notes</h2>
|
||
<ul>
|
||
<li>The tree of definition being used to build the repository, and the package directories must <strong>not</strong> be symlinks.</li>
|
||
<li>To build a repository is not required to hold the packages artifacts, only the respective <code>metadata.yaml</code> file is required.</li>
|
||
</ul>
|
||
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Docs: CLI usage</title>
|
||
<link>https://luet.io/docs/concepts/overview/usage/</link>
|
||
<pubDate>Sat, 14 Dec 2019 00:00:00 +0000</pubDate>
|
||
|
||
<guid>https://luet.io/docs/concepts/overview/usage/</guid>
|
||
<description>
|
||
|
||
|
||
<h2 id="installing-a-package">Installing a package</h2>
|
||
<p>To install a package with <code>luet</code>, simply run:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">
|
||
$ luet install &lt;package_name&gt;
|
||
|
||
</code></pre></div><p>To relax dependency constraints and avoid auto-upgrades, add the <code>--relax</code> flag:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">$ luet install --relax &lt;package name&gt;
|
||
</code></pre></div><p>To install only the package without considering the deps, add the <code>--nodeps</code> flag:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">$ luet install --nodeps &lt;package name&gt;
|
||
</code></pre></div><p>To install only package dependencies, add the <code>--onlydeps</code> flag:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">$ luet install --onlydeps &lt;package name&gt;
|
||
</code></pre></div><p>To only download packages, without installing them use the <code>--download-only</code> flag:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">$ luet install --download-only &lt;package name&gt;
|
||
</code></pre></div><h2 id="uninstalling-a-package">Uninstalling a package</h2>
|
||
<p>To uninstall a package with <code>luet</code>, simply run:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">
|
||
$ luet uninstall &lt;package_name&gt;
|
||
|
||
</code></pre></div><h2 id="upgrading-the-system">Upgrading the system</h2>
|
||
<p>To upgrade your system, simply run:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">$ luet upgrade
|
||
</code></pre></div><h2 id="refreshing-repositories">Refreshing repositories</h2>
|
||
<p>Luet automatically syncs repositories definition on the machine when necessary, but it avoids to sync up in a 24h range. In order to refresh the repositories manually, run:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">$ luet repo update
|
||
</code></pre></div><h2 id="searching-a-package">Searching a package</h2>
|
||
<p>To search a package:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">
|
||
$ luet search &lt;regex&gt;
|
||
|
||
</code></pre></div><p>To search a package and display results in a table:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">
|
||
$ luet search --table &lt;regex&gt;
|
||
|
||
</code></pre></div><p>To look into the installed packages:</p>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">
|
||
$ luet search --installed &lt;regex&gt;
|
||
|
||
</code></pre></div><p>Note: the regex argument is optional</p>
|
||
<h2 id="search-file-belonging-to-packages">Search file belonging to packages</h2>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">$ luet search --file &lt;file_pattern&gt;
|
||
</code></pre></div><h3 id="search-output">Search output</h3>
|
||
<p>Search can return results in the terminal in different ways: as terminal output, as json or as yaml.</p>
|
||
<h4 id="json">JSON</h4>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">
|
||
$ luet search --json &lt;regex&gt;
|
||
|
||
</code></pre></div><h4 id="yaml">YAML</h4>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">
|
||
$ luet search --yaml &lt;regex&gt;
|
||
|
||
</code></pre></div><h4 id="tabular">Tabular</h4>
|
||
<div class="highlight"><pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">
|
||
$ luet search --table &lt;regex&gt;
|
||
|
||
</code></pre></div><h2 id="quiet-luet-output">Quiet luet output</h2>
|
||
<p>Luet output is verbose by default and colourful, however will try to adapt to the terminal, based on which environment is executed (as a service, in the terminal, etc.)</p>
|
||
<p>You can quiet <code>luet</code> output with the <code>--quiet</code> flag or <code>-q</code> to have a more compact output in all the commands.</p>
|
||
|
||
</description>
|
||
</item>
|
||
|
||
<item>
|
||
<title>Docs: CSP, SAT && RL</title>
|
||
<link>https://luet.io/docs/concepts/overview/constraints/</link>
|
||
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
|
||
|
||
<guid>https://luet.io/docs/concepts/overview/constraints/</guid>
|
||
<description>
|
||
|
||
|
||
<p>Under the hood, Luet uses boolean satisfiability problem (<a href="https://en.wikipedia.org/wiki/Boolean_satisfiability_problem">SAT</a>) <a href="https://en.wikipedia.org/wiki/Reinforcement_learning">reinforcement learning</a> techniques to solve package constraints.</p>
|
||
<p>Luet allows you to specify 3 types of set of contraints on a <a href="https://luet.io/docs/docs/concepts/packages/">package</a> definition:</p>
|
||
<ul>
|
||
<li>Requires</li>
|
||
<li>Conflicts</li>
|
||
<li>Provides</li>
|
||
</ul>
|
||
<p>The package definition in your tree definition, along with its Requires and Conflicts, are turned into Boolean formulas that are consumed by the solver to compute a solution. The solution represent the state of your system after a particular query is asked to the solver (Install, Uninstall, Upgrade).</p>
|
||
<h2 id="requires-and-conflicts">Requires and Conflicts</h2>
|
||
<p>A list of requires and conflicts, composed of one or more <a href="https://luet.io/docs/docs/concepts/packages/">packages</a>, 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.</p>
|
||
<p>As Luet allows to express constraints with selectors ( e.g. <code>A depends on &gt;=B-1.0</code>) it generates additional constraints to guarantee that at least one package and at most one is picked as dependency (<em>ALO</em> and <em>AMO</em>).</p>
|
||
<h2 id="provides">Provides</h2>
|
||
<p>Provides constraints are not encoded in a SAT formula. Instead, they are <code>expanded</code> into an in-place substitution of the packages that they have to be replaced with.
|
||
They share the same SAT logic of expansion, allowing to swap entire version ranges (e.g. <code>&gt;=1.0</code>), allowing to handle package rename, removals, and virtuals.</p>
|
||
<h2 id="references">References</h2>
|
||
<ul>
|
||
<li>OPIUM (Luet is inspired by it): <a href="https://ranjitjhala.github.io/static/opium.pdf">https://ranjitjhala.github.io/static/opium.pdf</a></li>
|
||
<li>FROM TRACTABLE CSP TO TRACTABLE SAT: <a href="https://www.cs.ox.ac.uk/files/4014/maxclosed_orderencoding_v16_TR.pdf">https://www.cs.ox.ac.uk/files/4014/maxclosed_orderencoding_v16_TR.pdf</a></li>
|
||
<li>Solver concepts applied to packages (<code>zypper</code>): <a href="https://en.opensuse.org/openSUSE:Libzypp_satsolver_basics">https://en.opensuse.org/openSUSE:Libzypp_satsolver_basics</a></li>
|
||
</ul>
|
||
|
||
</description>
|
||
</item>
|
||
|
||
</channel>
|
||
</rss>
|