mirror of
https://github.com/mudler/luet.git
synced 2025-06-23 14:07:35 +00:00
311 lines
36 KiB
XML
311 lines
36 KiB
XML
|
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
|
|||
|
<channel>
|
|||
|
<title>Luet – Tutorials</title>
|
|||
|
<link>https://luet-lab.github.io/docs/docs/tutorials/</link>
|
|||
|
<description>Recent content in Tutorials on Luet</description>
|
|||
|
<generator>Hugo -- gohugo.io</generator>
|
|||
|
<lastBuildDate>Wed, 04 Jan 2017 00:00:00 +0000</lastBuildDate>
|
|||
|
|
|||
|
<atom:link href="https://luet-lab.github.io/docs/docs/tutorials/index.xml" rel="self" type="application/rss+xml" />
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<item>
|
|||
|
<title>Docs: Hello world!</title>
|
|||
|
<link>https://luet-lab.github.io/docs/docs/tutorials/hello_world/</link>
|
|||
|
<pubDate>Wed, 04 Jan 2017 00:00:00 +0000</pubDate>
|
|||
|
|
|||
|
<guid>https://luet-lab.github.io/docs/docs/tutorials/hello_world/</guid>
|
|||
|
<description>
|
|||
|
|
|||
|
|
|||
|
<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>
|
|||
|
<script id="asciicast-388348" src="https://asciinema.org/a/388348.js" data-autoplay="true" data-size="small" data-cols="120" data-rows="40" async></script>
|
|||
|
<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>
|
|||
|
<h2 id="busybox">busybox</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">mkdir busybox
|
|||
|
</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>
|
|||
|
<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">cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; busybox/build.yaml
|
|||
|
</span><span style="color:#4e9a06">image: &#34;busybox:{{.Values.version}}-glibc&#34;
|
|||
|
</span><span style="color:#4e9a06">EOF</span>
|
|||
|
</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>
|
|||
|
<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">cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; busybox/definition.yaml
|
|||
|
</span><span style="color:#4e9a06">category: &#34;distro&#34;
|
|||
|
</span><span style="color:#4e9a06">name: &#34;busybox&#34;
|
|||
|
</span><span style="color:#4e9a06">version: &#34;1.33.0&#34;
|
|||
|
</span><span style="color:#4e9a06">EOF</span>
|
|||
|
</code></pre></div><h2 id="golang">golang</h2>
|
|||
|
<p>We need now golang in order to build <code>gogs</code>. Let&rsquo;s declare then a golang 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">mkdir golang
|
|||
|
</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>
|
|||
|
<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">cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; golang/build.yaml
|
|||
|
</span><span style="color:#4e9a06">requires:
|
|||
|
</span><span style="color:#4e9a06">- category: &#34;distro&#34;
|
|||
|
</span><span style="color:#4e9a06"> name: &#34;busybox&#34;
|
|||
|
</span><span style="color:#4e9a06"> version: &#34;&gt;=0&#34;
|
|||
|
</span><span style="color:#4e9a06">
|
|||
|
</span><span style="color:#4e9a06">prelude:
|
|||
|
</span><span style="color:#4e9a06">- wget https://golang.org/dl/go{{.Values.version}}.linux-{{.Values.arch}}.tar.gz -O golang.tar.gz
|
|||
|
</span><span style="color:#4e9a06">- mkdir /usr/local
|
|||
|
</span><span style="color:#4e9a06">steps:
|
|||
|
</span><span style="color:#4e9a06">- tar -C /usr/local -xzf golang.tar.gz
|
|||
|
</span><span style="color:#4e9a06">EOF</span>
|
|||
|
</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>
|
|||
|
<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">cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; golang/definition.yaml
|
|||
|
</span><span style="color:#4e9a06">name: &#34;go&#34;
|
|||
|
</span><span style="color:#4e9a06">category: &#34;dev-lang&#34;
|
|||
|
</span><span style="color:#4e9a06">version: &#34;1.15.6&#34;
|
|||
|
</span><span style="color:#4e9a06">arch: &#34;amd64&#34;
|
|||
|
</span><span style="color:#4e9a06">EOF</span>
|
|||
|
</code></pre></div><h2 id="gogs">gogs</h2>
|
|||
|
<p>Finally we can write the gogs package definition!</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">mkdir gogs
|
|||
|
</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>
|
|||
|
<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">cat <span style="color:#4e9a06">&lt;&lt;&#39;EOF&#39; &gt; gogs/build.yaml
|
|||
|
</span><span style="color:#4e9a06">requires:
|
|||
|
</span><span style="color:#4e9a06">- category: &#34;dev-lang&#34;
|
|||
|
</span><span style="color:#4e9a06"> name: &#34;go&#34;
|
|||
|
</span><span style="color:#4e9a06"> version: &#34;&gt;=0&#34;
|
|||
|
</span><span style="color:#4e9a06">env:
|
|||
|
</span><span style="color:#4e9a06">- GOPATH=&#34;/go&#34;
|
|||
|
</span><span style="color:#4e9a06">- GOGSPATH=&#34;$GOPATH/src/github.com/gogs/gogs&#34;
|
|||
|
</span><span style="color:#4e9a06">- PATH=$PATH:/usr/local/go/bin
|
|||
|
</span><span style="color:#4e9a06">- CGO_ENABLED=0
|
|||
|
</span><span style="color:#4e9a06">prelude:
|
|||
|
</span><span style="color:#4e9a06">- mkdir -p $GOPATH/src/github.com/gogs
|
|||
|
</span><span style="color:#4e9a06">- wget https://github.com/gogs/gogs/archive/v{{.Values.version}}.tar.gz -O - | tar -xzf - -C ./ &amp;&amp; mv gogs-{{.Values.version}} $GOGSPATH
|
|||
|
</span><span style="color:#4e9a06">steps:
|
|||
|
</span><span style="color:#4e9a06">- mkdir /usr/bin
|
|||
|
</span><span style="color:#4e9a06">- cd $GOGSPATH &amp;&amp; go build &amp;&amp; mv gogs /usr/bin/gogs
|
|||
|
</span><span style="color:#4e9a06">excludes:
|
|||
|
</span><span style="color:#4e9a06"># Cache generated by Golang
|
|||
|
</span><span style="color:#4e9a06">- ^/root
|
|||
|
</span><span style="color:#4e9a06">EOF</span>
|
|||
|
</code></pre></div><p>And the metadata, in this way we can refer to gogs in a Luet tree:</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">cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; gogs/definition.yaml
|
|||
|
</span><span style="color:#4e9a06">category: &#34;dev-vcs&#34;
|
|||
|
</span><span style="color:#4e9a06">name: &#34;gogs&#34;
|
|||
|
</span><span style="color:#4e9a06">version: &#34;0.11.91&#34;
|
|||
|
</span><span style="color:#4e9a06">EOF</span>
|
|||
|
</code></pre></div><h1 id="build-packages">Build packages</h1>
|
|||
|
<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>
|
|||
|
<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 dev-vcs/gogs
|
|||
|
</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>
|
|||
|
|
|||
|
</description>
|
|||
|
</item>
|
|||
|
|
|||
|
<item>
|
|||
|
<title>Docs: Build a package</title>
|
|||
|
<link>https://luet-lab.github.io/docs/docs/tutorials/build_package/</link>
|
|||
|
<pubDate>Wed, 04 Jan 2017 00:00:00 +0000</pubDate>
|
|||
|
|
|||
|
<guid>https://luet-lab.github.io/docs/docs/tutorials/build_package/</guid>
|
|||
|
<description>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<div class="alert alert-warning" role="alert">
|
|||
|
<h4 class="alert-heading">Warning</h4>
|
|||
|
|
|||
|
This article contains references to Luet repositories that were deprecated, and needs to be updated.
|
|||
|
Please refer to the <a href="../../tutorials/hello_world/">&ldquo;Hello World&rdquo;</a> tutorial instead.
|
|||
|
|
|||
|
</div>
|
|||
|
|
|||
|
<p><img src="https://github.com/BarkyTheDog/catclock/raw/master/catclock.gif" alt="catclock"></p>
|
|||
|
<h1 id="catclock-example">Catclock example</h1>
|
|||
|
<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>
|
|||
|
</ol>
|
|||
|
<h2 id="prerequisites">Prerequisites</h2>
|
|||
|
<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"># Let&#39;s create a directory to store our package spec:</span>
|
|||
|
mkdir -p tree/misc/catclock/
|
|||
|
</code></pre></div><h3 id="11-build-spec">1.1) Build spec</h3>
|
|||
|
<p>Now, let&rsquo;s generate our <strong>build</strong> spec:</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>
|
|||
|
cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; tree/misc/catclock/build.yaml
|
|||
|
</span><span style="color:#4e9a06">image: opensuse/leap
|
|||
|
</span><span style="color:#4e9a06">
|
|||
|
</span><span style="color:#4e9a06"># Preparation phase
|
|||
|
</span><span style="color:#4e9a06">prelude:
|
|||
|
</span><span style="color:#4e9a06">- zypper in -y git make libXt-devel xmh gcc motif-devel libXext-devel libpulse-devel libaubio-devel
|
|||
|
</span><span style="color:#4e9a06">- git clone https://github.com/BarkyTheDog/catclock
|
|||
|
</span><span style="color:#4e9a06">
|
|||
|
</span><span style="color:#4e9a06"># Here we define the steps that Luet will follow
|
|||
|
</span><span style="color:#4e9a06">steps:
|
|||
|
</span><span style="color:#4e9a06">- cd catclock &amp;&amp; make DEFINES=&#34;-Wno-incompatible-pointer-types&#34;
|
|||
|
</span><span style="color:#4e9a06">- mv catclock/xclock /usr/bin/xclock
|
|||
|
</span><span style="color:#4e9a06">
|
|||
|
</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)
|
|||
|
</span><span style="color:#4e9a06">includes:
|
|||
|
</span><span style="color:#4e9a06">- /usr/bin/xclock
|
|||
|
</span><span style="color:#4e9a06">EOF</span>
|
|||
|
|
|||
|
</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>
|
|||
|
</ul>
|
|||
|
<h3 id="12-runtime-spec">1.2) Runtime spec</h3>
|
|||
|
<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>
|
|||
|
<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 runtime definition.</span>
|
|||
|
<span style="color:#8f5902;font-style:italic"># We will leverage packages already present on Sabayon Entropy repositories</span>
|
|||
|
<span style="color:#8f5902;font-style:italic"># the end-system needs to have the Luet Sabayon Entropy repositories enabled.</span>
|
|||
|
cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; tree/misc/catclock/definition.yaml
|
|||
|
</span><span style="color:#4e9a06">category: &#34;misc&#34;
|
|||
|
</span><span style="color:#4e9a06">name: &#34;catclock&#34;
|
|||
|
</span><span style="color:#4e9a06">version: &#34;0.20200318&#34;
|
|||
|
</span><span style="color:#4e9a06">requires:
|
|||
|
</span><span style="color:#4e9a06">- category: meta
|
|||
|
</span><span style="color:#4e9a06"> name: users
|
|||
|
</span><span style="color:#4e9a06"> version: &#34;&gt;=0&#34;
|
|||
|
</span><span style="color:#4e9a06">- category: x11-libs
|
|||
|
</span><span style="color:#4e9a06"> name: motif
|
|||
|
</span><span style="color:#4e9a06"> version: &#34;&gt;=0.1&#34;
|
|||
|
</span><span style="color:#4e9a06">- category: media-libs
|
|||
|
</span><span style="color:#4e9a06"> name: libjpeg-turbo
|
|||
|
</span><span style="color:#4e9a06"> version: &#34;&gt;=0.1&#34;
|
|||
|
</span><span style="color:#4e9a06">EOF</span>
|
|||
|
</code></pre></div><ul>
|
|||
|
<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>
|
|||
|
</ul>
|
|||
|
<h2 id="2-build-it">2) Build it!</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">sudo /usr/bin/luet build <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--tree<span style="color:#ce5c00;font-weight:bold">=</span><span style="color:#000">$PWD</span>/tree misc/catclock <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--destination <span style="color:#000">$PWD</span>/build <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--compression gzip
|
|||
|
|
|||
|
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>
|
|||
|
<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">/usr/bin/luet create-repo --tree <span style="color:#4e9a06">&#34;tree&#34;</span> <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--output <span style="color:#000">$PWD</span>/build <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--packages <span style="color:#000">$PWD</span>/build <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--name <span style="color:#4e9a06">&#34;test repo&#34;</span> <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--descr <span style="color:#4e9a06">&#34;Test Repo&#34;</span> <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--tree-compression gzip <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--meta-compression gzip
|
|||
|
</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>name</strong>: Repository name</li>
|
|||
|
<li><strong>descr</strong>: Repository description</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>
|
|||
|
<span style="color:#8f5902;font-style:italic"># our amazing catclock</span>
|
|||
|
mkdir -p <span style="color:#000">$PWD</span>/rootfs
|
|||
|
</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>
|
|||
|
mkdir -p <span style="color:#000">$PWD</span>/conf
|
|||
|
</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>
|
|||
|
cat <span style="color:#4e9a06">&lt;&lt;EOF &gt; conf/luet-dso-local.yaml
|
|||
|
</span><span style="color:#4e9a06">system:
|
|||
|
</span><span style="color:#4e9a06"> rootfs: $PWD/rootfs # our &#34;fake&#34; rootfs that we created before
|
|||
|
</span><span style="color:#4e9a06"> database_path: &#34;/&#34; # this is where our Luet DB will live
|
|||
|
</span><span style="color:#4e9a06"> database_engine: &#34;boltdb&#34; # this is the Luet DB engine
|
|||
|
</span><span style="color:#4e9a06">repositories:
|
|||
|
</span><span style="color:#4e9a06"> - name: &#34;main&#34;
|
|||
|
</span><span style="color:#4e9a06"> type: &#34;disk&#34;
|
|||
|
</span><span style="color:#4e9a06"> priority: 3
|
|||
|
</span><span style="color:#4e9a06"> enable: true
|
|||
|
</span><span style="color:#4e9a06"> urls:
|
|||
|
</span><span style="color:#4e9a06"> - &#34;$PWD/build&#34; # This is the repository we have created before!
|
|||
|
</span><span style="color:#4e9a06"> - name: &#34;sabayonlinux.org&#34;
|
|||
|
</span><span style="color:#4e9a06"> description: &#34;Sabayon Linux Repository&#34;
|
|||
|
</span><span style="color:#4e9a06"> type: &#34;http&#34;
|
|||
|
</span><span style="color:#4e9a06"> enable: true
|
|||
|
</span><span style="color:#4e9a06"> cached: true
|
|||
|
</span><span style="color:#4e9a06"> priority: 2
|
|||
|
</span><span style="color:#4e9a06"> urls:
|
|||
|
</span><span style="color:#4e9a06"> - &#34;https://dispatcher.sabayon.org/sbi/namespace/luet-entropy-repo&#34;
|
|||
|
</span><span style="color:#4e9a06"> - name: &#34;luet-repo&#34;
|
|||
|
</span><span style="color:#4e9a06"> description: &#34;Luet Official Repository&#34;
|
|||
|
</span><span style="color:#4e9a06"> type: &#34;http&#34;
|
|||
|
</span><span style="color:#4e9a06"> enable: true
|
|||
|
</span><span style="color:#4e9a06"> cached: true
|
|||
|
</span><span style="color:#4e9a06"> priority: 1
|
|||
|
</span><span style="color:#4e9a06"> urls:
|
|||
|
</span><span style="color:#4e9a06"> - &#34;https://raw.githubusercontent.com/Luet-lab/luet-repo/gh-pages&#34;
|
|||
|
</span><span style="color:#4e9a06">EOF</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>
|
|||
|
<span style="color:#8f5902;font-style:italic"># user-level support.</span>
|
|||
|
<span style="color:#204a87">export</span> <span style="color:#000">LUET_NOLOCK</span><span style="color:#ce5c00;font-weight:bold">=</span><span style="color:#204a87">true</span>
|
|||
|
luet install <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--config <span style="color:#000">$PWD</span>/conf/luet-dso-local.yaml <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>meta/users
|
|||
|
</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>
|
|||
|
cp -rfv <span style="color:#000">$HOME</span>/.Xauthority <span style="color:#000">$PWD</span>/rootfs/
|
|||
|
</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">luet install <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--config <span style="color:#000">$PWD</span>/conf/luet-dso-local.yaml <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>misc/catclock
|
|||
|
</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 run our beautiful catclock :)</span>
|
|||
|
luet box <span style="color:#204a87">exec</span> --rootfs <span style="color:#000">$PWD</span>/rootfs <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--stdin --stdout --stderr --env <span style="color:#000">DISPLAY</span><span style="color:#ce5c00;font-weight:bold">=</span><span style="color:#000">$DISPLAY</span> <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--env <span style="color:#000">XAUTHORITY</span><span style="color:#ce5c00;font-weight:bold">=</span>/.Xauthority --mount /tmp --entrypoint /usr/bin/xclock
|
|||
|
</code></pre></div><p>Spawn a bash shell inside our box (with permission to access to our running X):</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 box <span style="color:#204a87">exec</span> --rootfs <span style="color:#000">$PWD</span>/rootfs <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--stdin --stdout --stderr --env <span style="color:#000">DISPLAY</span><span style="color:#ce5c00;font-weight:bold">=</span><span style="color:#000">$DISPLAY</span> <span style="color:#4e9a06">\
|
|||
|
</span><span style="color:#4e9a06"></span>--env <span style="color:#000">XAUTHORITY</span><span style="color:#ce5c00;font-weight:bold">=</span>/.Xauthority --mount /tmp --entrypoint /bin/bash
|
|||
|
</code></pre></div>
|
|||
|
</description>
|
|||
|
</item>
|
|||
|
|
|||
|
</channel>
|
|||
|
</rss>
|