<p>This article will guide you to build your first package with Luet!
For this purpose, we have picked a real-world example: <a href="https://github.com/gogs/gogs">gogs</a> which is a &ldquo;painless self-hosted Git service&rdquo;, an open-source alternative to Github.</p>
<p>Gogs is written in Golang, and we need a working Golang version in order to build it.</p>
<p>Here you can see a live recorded session of this tutorial:</p>
<h1 id="define-a-luet-tree">Define a Luet tree</h1>
<p>Everything starts from a Luet tree. A Luet tree is just a directory containing one (or more) Luet specfile, here on we assume that you are working in a dedicated folder (e.g. <code>~/demo</code>) in your system.</p>
<p>Let&rsquo;s create then a package that will be our base to build other packages from now on, we have picked <code>busybox</code> here - it is really small and enough for our purpose.</p>
</code></pre></div><p>Let&rsquo;s now write the build specification, which is just containing the image tag that we are referencing to</p>
</code></pre></div><p>Now, lets write the <code>definition.yaml</code>, which contains the metadata information about our package ( e.g. how we refer to it with luet, the version, and so on )</p>
</code></pre></div><p>And a build specfile, which is simply fetch golang from <a href="https://golang.org">https://golang.org</a> and installing it in the busybox container:</p>
</code></pre></div><p>Note how we <code>require</code> busybox. The Golang container will now be based from busybox, and the <code>prelude</code> and <code>steps</code> fields will be executed in that context.</p>
<p>And finally let&rsquo;s write the golang metadata files, so we can refer to it from other packages</p>
</code></pre></div><p>The build specfile, will just fetch the <code>gogs</code> sources at a given version (specified in the <code>definition.yaml</code>) and build the sources with go:</p>
<p>The simplest and mostly immediate way to build packages, is running <code>luet build &lt;packagename&gt;</code> in the same folder you have your Luet tree.</p>
<p>In this case, to build gogs and its deps, we can do:</p>
</code></pre></div><p>And that&rsquo;s it! you will find the package archives in <code>build/</code> in the same folder where you started the command.</p>
<p>You will see that Luet generates not only archives with the file resulting to your builds, but it will also generate metadata files (ending with <code>.metadata.yaml</code>) that contains additional metadata information about your build and the package itself (e.g. checksums).</p>
<p>You can use tools like <a href="https://github.com/mikefarah/yq">yq</a> to inspect those:</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">yq r build/gogs-dev-vcs-0.11.91.metadata.yaml checksums
</code></pre></div><p>Now if you want to consume the artifacts just built with <code>luet install</code>, you can create a repository with <code>luet create-repo</code>.</p>
<p>In this example, we will build the awesome <a href="https://github.com/BarkyTheDog/catclock">CatClock</a> on containers we will run it locally in a Luet box.</p>
<p>We will do this experiment to prove two things:</p>
<ol>
<li>how we can build a package with Luet and</li>
<li>two packages from different distributions can (sometime) work together.</li>
<p>To build packages with Luet, you must have installed Docker and container-diff, follow our <a href="../../getting-started">setup guide</a>.</p>
<h2 id="1-create-the-package">1) Create the package</h2>
<p>To prove our point, we will build our package from an OpenSUSE image, and later on we will consume
entropy repositories for runtime dependencies. To note, this is not the main focus of Luet, and this is a restricted example on its features on build-time resolution. For more syntax examples, see also <a href="../../concepts/specfile/#build-specs">Build specs</a> and <a href="../../concepts/packages/#package-types">Package types</a>.</p>
<p>Run this commands in any directory you choose to be your workspace:</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"><span style="color:#8f5902;font-style:italic"># Create a build file. We use here opensuse/leap to build the package, as an example</span>
</span><span style="color:#4e9a06"># (optional) File list that will be included in the final package
</span><span style="color:#4e9a06"># Luet will filter out files that won&#39;t match any entry in the list (regex syntax IS supported)
</code></pre></div><p><code>build.yaml</code> is what an ebuild is for Gentoo and for e.g. what PKGBUILD is for Arch.</p>
<ul>
<li><em>image: opensuse/leap</em> tells luet to use opensuse/leap as a build image. We collect the build time dependencies with <code>zypper</code> (the openSUSE package manager), and the <a href="https://github.com/BarkyTheDog/catclock">CatClock</a> with <code>git</code>. When we declare an <code>image</code> keyword in a spec, it becomes a <em>seed</em> package ( <a href="../../concepts/packages/#package-types">Package types</a> ) as doesn&rsquo;t depend on any package in build time, we will cover more use cases in other examples.</li>
<li><em>prelude</em> is a list of commands that will happen during the build phase.
They might generate binaries, or download sources, but those are not took into consideration when generating the final package.</li>
<li><em>steps</em> is a list of commands that will happen during the build phase.
Luet will execute those commands and all the binaries generated from them become part of the final package</li>
<li><em>includes</em> is a (optional) list of regex that tells to Luet what files to filter out from the final artifact.</li>
<p>Now we generate the runtime spec, it&rsquo;s the part about the binary end which will be installed in the system. It also holds the metadata relative to the package definition (<code>name</code>, <code>category</code>, <code>version</code>).</p>
<li><em>category</em>, <em>name</em>, and <em>version</em>: identifies the package in a Luet tree. This is the unique identifier for a package.</li>
<li><em>requires</em> it&rsquo;s a list of packages which our <strong>catclock</strong> depends on during runtime (when we will execute catclock inside a small-container!). To find out what&rsquo;s required by your binaries it can be a try-learn-fail effort. If the package you wish to build is specifying the deps it requires, and those are available in a Luet repository, you are all set, just point them there. Otherwise you have to figure out after you build the binary the first time (for example, with <code>ldd</code>) to which libraries it depends on.
In this example we consume the dependencies from the <a href="https://github.com/Luet-lab/luet-entropy-repo">Luet Entropy Repo</a>, that we will enable on the following steps.</li>
sudo chown -R <span style="color:#000">$USER</span><span style="color:#000">$PWD</span>/build <span style="color:#8f5902;font-style:italic"># So later on, we can access to the repository with our user</span>
</code></pre></div><p>We are building the specs in this step.</p>
<ul>
<li><em>tree</em>: is the path where our specs are, in our case it&rsquo;s <code>tree</code>.</li>
<li><em>destination</em>: is the path where our packages will be stored, in our case this is <code>build</code>.</li>
<li><em>compression</em>: is the compression algorithm used to compress the final artifacts</li>
</ul>
<p>Note, we need <em>sudo</em> to keep the permissions properly mapped in the artifact which is produced
this is not always the case. Depends on the package content.</p>
<h2 id="3-create-a-local-repository">3) Create a local repository</h2>
<p>We will generate now our repository metadata:</p>
</code></pre></div><p>Creating a repository in Luet is about adding metadata and make our spec tree available to other systems running Luet to intall the package.</p>
<ul>
<li><strong>output</strong>: a path which is where Luet will store the repository metadata.</li>
<li><strong>packages</strong>: a path containing the packages that were built during the build step</li>
<li><strong>tree-compression</strong>: optional, algorithm to use when compression the tree metadata</li>
<li><strong>meta-compression</strong>: optional, algorithm to use when compression the repository metadata</li>
</ul>
<h2 id="4-lets-test-it">4) Let&rsquo;s test it!</h2>
<p>Now we are all set. We have the packages compiled, and we are ready to consume them. We don&rsquo;t want to break our host system, and we want to test this from our user.</p>
<p>Let&rsquo;s create a directory, we will try to setup a full running system, and install everything there.</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"><span style="color:#8f5902;font-style:italic"># Let&#39;s create a directory for our &#34;fake&#34; rootfilesystem</span>
<span style="color:#8f5902;font-style:italic"># it will be populated with a minimal set of packages needed to run </span>
</code></pre></div><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"><span style="color:#8f5902;font-style:italic"># Let&#39;s also create a directory to store our config files</span>
</code></pre></div><p>We will generate now a Luet config. The Luet config is used to read where install things from, and in which directory.
It also lists the repositories that are used by the client to retrieve packages remotely.</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"><span style="color:#8f5902;font-style:italic"># We create here a config file which references the rootfs.</span>
<span style="color:#8f5902;font-style:italic"># In this way, luet instead installing packages to your host system, will populate the rootfs</span>
<span style="color:#8f5902;font-style:italic"># (note, all the steps are run by a user here, no root required!)</span>
<span style="color:#8f5902;font-style:italic"># we have specified an additional repository, one that is luet-entropy-repo (which contains</span>
<span style="color:#8f5902;font-style:italic"># the runtime dependencies we specified in our package)</span>
</code></pre></div><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"><span style="color:#8f5902;font-style:italic"># Let&#39;s populate our rootfs with some minimal things: base-gcc, and bash</span>
<span style="color:#8f5902;font-style:italic"># meta/users is a meta package providing minimal base to run things with a full</span>
</code></pre></div><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"><span style="color:#8f5902;font-style:italic"># catclock is a X11 app! we want to be able to play with it locally from our host :)</span>
<span style="color:#8f5902;font-style:italic"># Let&#39;s copy the .Xauthority file to allow the X app to communicate with our X server</span>
<span style="color:#8f5902;font-style:italic"># Note: This can be achieved in other ways (set up a tcp X server, and so on)</span>