everest-web/docs/intro-to-glacier.html
2024-09-17 09:44:39 -04:00

271 lines
15 KiB
HTML

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Everest Linux - Docs</title>
<link type="text/css" rel="stylesheet" href="../css/nord.css"/>
<link rel="icon" type="image/x-icon" href="../img/favicon.svg"/>
</head>
<body>
<!-- Navbar -->
<div class="sidenav">
<img src="../img/everest-nord.svg" alt="everest-logo">
<a href="../index.html">Home</a>
<a href="../about.html">About</a>
<a href="../install.html">Install</a>
<a href="../packages.html">Packages</a>
<a href="../download.html">Downloads</a>
<a href="home.html">Docs</a>
<a href="../errata.html">Errata</a>
<a href="https://git.everestlinux.org">Git ↗</a>
</div>
<!-- Rest of page -->
<div class="main">
<button onclick="window.location.href='home.html';">
Back to home
</button>
<h2>1 - Introduction</h2>
<p>Glacier is the package management system for Glacier. All users should be familiar with how it works.</p>
<h2>2 - Package Indexes</h2>
<p>On an Everest system, packages are stored in an "index", of which there are two, the <i>system</i> index and the <i>user</i> index.</p>
<p>The system index is located in <cil>/glacier/index</cil>, and the user index is localed in <cil>/usr/glacier/index</cil>.</p>
<p>When you merge a package from a repository, <cil>gpkg</cil> will retrieve the file, execute the relevant instruction sets, and store the package in the user index. <cil>syspkg</cil> will operate on the system index instead. On update, <cil>gpkg</cil> will retrieve the package from the user index and execute the relevant instruction sets. The package will then be moved back into the user index. On removal, the package will be moved to <cil>/tmp</cil> oncde the removal instructions have been executed.</p>
<h2>3 - Repositories</h2>
<p>Unlike most distributions, Everest installations include a copy of the package repository on the local system. Rather than downloading packages from a remote server, Glacier clones a package from the local repository.</p>
<p>This presents some advantages:</p>
<ul>
<li><p>Package modifications can be done easily</p></li>
<li><p>In the result of connection loss, Glacier can still be used</p></li>
</ul>
<p>And also some disadvantages:</p>
<ul>
<li><p>Security risks may surface if the repository is not kept updated or an unauthorized party makes changes to packages</p></li>
</ul>
<p>The <cil>glacier-update-pkgdb</cil> program can be used to update the local repository. This should be done regularly (at least once a week) to ensure the newest and most secure packages are available.</p>
<h2>4 - The System Profile</h2>
<p>An Everest installation includes a system profile. In simple terms, this is a series of environment variables and configurations that tell Glacier which packages it can install. The system profile should not change unless the user intends to migrate profiles.</p>
<p>The following environment variables are defined by the system profile:</p>
<ul>
<li><p><cil>GLACIER_REPO</cil> - The repository which will be downloaded by <cil>glacier-update-pkgdb</cil></p></li>
<li><p><cil>GLACIER_ARCH</cil> - The CPU's architecture</p></li>
<li><p><cil>GLACIER_TARGET</cil> - The compilation triplet</p></li>
<li><p><cil>GLACIER_SYSTEM_PROFILE</cil> - The name of the system profile</p></li>
</ul>
<p>The following system profiles are available:</p>
<ul>
<li><p><cil>x86_64-musl</cil></p></li>
</ul>
<p>The following system profiles are planned for the future:</p>
<ul>
<li><p><cil>x86_64-glibc</cil></p></li>
<li><p><cil>x86_64-musl-nomultilib</cil></p></li>
<li><p><cil>x86_64-glibc-nomultilib</cil></p></li>
</ul>
<h2>5 - Included programs</h2>
<p><strong>3.1 </strong>gpkg</p>
<p><cil>gpkg</cil> is the program most users will be interacting with. It handles the downloading, installation, and logging of packages.</p>
<p><strong>3.2 </strong>syspkg</p>
<p><cil>syspkg</cil> is like <cil>gpkg</cil>, except it operates on the system index, rather than the local index. End users should not use this unless instructed to.</p>
<p><strong>3.3 </strong>glist</p>
<p><cil>glist</cil> lists all installed packages, allowing the user to filter by name.
<p><strong>3.4 </strong>gquery</p>
<p><cil>gquery</cil> queries information on a package.</p>
<p><strong>3.5 </strong>gpc</p>
<p><cil>gpc</cil> checks if the syntax of a package is correct. This can be used to troubleshoot a package refusing to install, but is mainly intended for package developers.</p>
<p><strong>3.6 </strong>glacier-mkprofile</p>
<p><cil>glacier-mkprofile</cil> makes changes to the system-wide profile. Users should not interact with this unless needed.</p>
<p><strong>3.7 </strong>glacier-update-pkdgb</p>
<p><cil>glacier-update-pkgdb</cil> syncs the local package database with the remote server. This command should be run periodically to ensure you have the most up-to-date packages.</p>
<h2>6 - Frontends</h2>
<p>Frontends, or wrappers, may provide additional functionality to Glacier.</p>
<warnhead><strong>WARNING:</strong></warnhead>
<div class="warning">
<p>Third party frontends and wrapper scripts are not supported. Use them at your own risk.</p>
</div>
<h2>7 - Merging packages</h2>
<p><strong>5.1 </strong>Using gpkg</p>
<p>To merge a package from a repository:</p>
<code>(root)# gpkg -f pkg</code>
<p>For instance, to install 'vim':</p>
<code>(root)# gpkg -f vim</code>
<p><strong>5.2 </strong>Using syspkg</p>
<p>Using <cil>syspkg</cil> is not recommended for end users because all changes to the global package index will be overwritten when pulling a new update.</p>
<p>If you understand these risks, and wish to use <cil>syspkg</cil> anyways, you are acknowledging that things may break.</p>
<p>To merge a package:</p>
<code>(root)# syspkg -f pkg</code>
<h2>8 - Updating packages</h2>
<p><strong>6.1 </strong>Introduction</p>
<p>When merging a package into any index, the package file is retained in said index. This provides most information needed to keep track of the package, however, when updating, an updated package file will need to be downloaded. Old package files will be retained as <cil>pkgname.old</cil>.</p>
<p><strong>6.2 </strong>Using gpkg</p>
<p>To update a package:</p>
<code>(root)# gpkg -u pkg</code>
<p><strong>6.3 </strong>Using syspkg</p>
<p>As mentioned above, <cil>syspkg</cil> is intended for system development, and NOT for end users.</p>
<p>However, <cil>syspkg -u</cil> has some use cases for end users. These include:</p>
<ul>
<li>Updating a system program WITHOUT pulling a new release from Git</li>
<li>Fixing urgent security vulnerabilities</li>
</ul>
<p>To update a package:</p>
<code>(root)# syspkg -u pkg</code>
<h2>9 - Removing packages</h2>
<p><strong>7.1 </strong>Introduction</p>
<p>When removing a package, the package info file is moved from the appropriate index to /tmp, and saved as <cil>pkgname.rm</cil>. This means it will be wiped after the next reboot.</p>
<p><strong>7.2 </strong>Using gpkg</p>
<p>To remove a package:</p>
<code>(root)# gpkg -x pkg</code>
<p>If a package is a dependency for another, you will be shown the following error:</p>
<code>[x] Could not remove (package_name): is a dependency for (package_name)</code>
<p><strong>7.3 </strong>Using syspkg</p>
<warnhead><strong>WARNING:</strong></warnhead>
<div class="warning">
<p>Removing packages that shipped with the system images WILL cause catastrophic damage. You have been warned.</p>
</div>
<p>If you wish to proceed anyways, you can remove a package with:</p>
<code>(root)# syspkg -x pkg</code>
<h2>10 - Advanced usage</h2>
<p><strong>8.1 </strong>Patching packages</p>
<p>Patching packages is the act of editing a package file to change compile options, optimizations, etc. It is very useful if used correctly.</p>
<p>The officially tested and verified method for patching is as follows:</p>
<ul>
<li>Download the package file with <cil>gpkg -d</cil></li>
<li>Edit the package file with a text editor of your choice</li>
<li>Install the locally modified package with <cil>gpkg -fl pkg</cil></li>
</ul>
<p><strong>8.2 </strong>Custom package repository</p>
<p>If Glacier's standard package repository is not sufficient, you can use a custom one.</p>
<warnhead><strong>WARNING:</strong></warnhead>
<div class="warning">
<p>Ensure the repository you wish to migrate to supports your system profile. For example, if your profile is <cil-inv>x86-musl</cil-inv>, the new repository should offer packages compatible with <cil-inv>x86-musl</cil-inv>.</p>
<p>Errors will occur if this is not taken into account.</p>
</div>
<p>To use a custom repository once, to merge a package:</p>
<code>(root)# GREPO=http://some-repo.org gpkg -f repo/pkg</code>
<p>To make the changes persistent, change the <cil>GREPO</cil> variable in <cil>/etc/glacier.conf</cil>:</p>
<fhead><strong>FILE:</strong> /etc/glacier.conf</fhead>
<div class="file">
<p>export GREPO="https://some-repo.org</p>
</div>
<p><strong>8.3 </strong>Compile flags</p>
<p>When an operation is performed on a package, 'gpkg' invokes the system's C compiler, which can take flags for compilation.</p>
<p>'MAKEFLAGS', 'CFLAGS', 'CXXFLAGS', and 'LDFLAGS' can be set in '/etc/make.conf'.</p>
<p>It is highly recommended to keep '-static' in 'CFLAGS' and 'LDFLAGS'.</p>
<p><strong>8.4 </strong>Using syspkg</p>
<p>'syspkg' is intended for development use and not for end users. That being said, 'syspkg' can be used for fixing security vulnerabilities without pulling in a new release from git.</p>
<p>Note that all changes to the global package index ('/glacier/index') will be overwritten during an update, where the user invokes 'git pull' on '/'.</p>
<p><strong>8.5 </strong>Whitelisting licenses</p>
<p>Certain license types can be whitelisted or blacklisted. This is useful for controlling which software is installed on your system.</p>
<p>This setting is stored in /etc/glacier.conf, in a simple Bash array. By default, it should look something like this:</p>
<fhead><strong>FILE:</strong> /etc/glacier.conf</fhead>
<div class="file">
<p>export GLACIER_ALLOWED_LICENSES=("GPL v3" "GPL v2" "GPL" "MIT" "BSD" "APACHE")</p>
</div>
<p><strong>8.6 </strong>Services</p>
<p>Glacier services are small programs that can do certain tasks within Glacier, such as updating the local package database.</p>
<p>Services must be enabled in /etc/glacier.conf before they can be used.</p>
<fhead><strong>FILE: </strong>/etc/glacier.conf</fhead>
<div class="file">
<p>export GLACIER_ALLOW_SERVICES="true"</p>
</div>
<p></p>
<warnhead><strong>WARNING:</strong></warnhead>
<div class="warning">
<p>Services can present a security risk to your system if not used properly. Ensure you review each service, its functions, and only use services made by users you trust.</p>
</div>
<p>Services can be configured to run at three different times: run (when an operation is started), pkg (when a package is installed), and end (when all pending operations have finished).</p>
<p>Create 3 files in /etc/glacier:</p>
<code>(root)# touch /etc/glacier/{call-srv,pkg-srv,end-srv}</code>
<p>There should be a directory in /etc/glacier containing service files. If not, create it now:</p>
<code>(root)# mkdir /etc/glacier/services</code>
<p>Now you can add services to the previously created files. For instance:</p>
<fhead><strong>FILE: </strong>/etc/glacier/end-srv</fhead>
<div class="file">
<p>#!/bin/bash</p>
<p>&nbsp;</p>
<p>GLACIER_SRV_DIR="/etc/glacier/services"</p>
<p>$GLACIER_SRV_DIR/update-pkgdb.hook</p>
</div>
<h2>11 - Querying packages</h2>
<p><strong>9.1 </strong>Introduction</p>
<p>Glacier packages, in ther simplest form, are text files, containing instructions on how the package is built, who made it, what it's called, and what files it includes.</p>
<p><strong>9.2 </strong>Querying files</p>
<p>All files belonging to a package can be listed with:</p>
<code>(user)$ gquery -f pkg</code>
<p><strong>9.3 </strong>Querying info</p>
<p>Package info can be listed with:</p>
<code>(user)$ gquery -i pkg</code>
<h2>12 - Writing packages</h2>
<notehead><strong>NOTE:</strong></notehead>
<div class="note">
<p>This section is outdated as of 9/17/2024</p>
<p>Reason: Glacier v4 changes the package format</p>
</div>
<p><strong>10.1 </strong>Introduction</p>
<p>As mentioned before, Glacier packages are simply text files. This makes them very easy to write and maintain.</p>
<p>If you have previous experience writing PKGBUILDs for the AUR, writing Glacier packages should feel very similar.</p>
<p>In this page, 'nano' will be used as an example.</p>
<p><strong>10.2 </strong>Metadata</p>
<p>Package files start with metadata, which tells Glacier who made the package, what its called, as well as other information.</p>
<p>Double check that all of this information is correct before submitting a package.</p>
<fhead><strong>FILE:</strong> $(pwd)/nano</fhead>
<div class="file">
<p>PACKAGE_NAME="nano"</p>
<p>PACKAGE_VER="7.2"</p>
<p>PACKAGE_DESC="The GNU nano text editor"</p>
<p>MAINTAINER="liamwaldron@everestlinux.org"</p>
<p>LICENSE="GPL v3"</p>
<p>ARCH="x86"</p>
<p>INCLUDED_FILES=("/usr/bin/nano" "/usr/bin/rnano")</p>
</div>
<p>Hopefully, most of these options are self explanatory.</p>
<p>For INCLUDED_FILES, ensure you DON'T include documentation (manpages, etc).</p>
<p><strong>10.3 </strong>Integrity information</p>
<fhead><strong>FILE:</strong> $(pwd)/nano</fhead>
<div class="file">
<p>SHA256SUMS="86f3442768bd2873cec693f83cdf80b4b444ad3cc14760b74361474fc87a4526"</p>
</div>
<p>All packages must include their checksums. When merging a package, 'gpkg' will check the provided checksum against the actual checksum of the package, and if they don't match, the operation will be cancelled.</p>
<p>To get the checksum of a package:</p>
<code>(user)$ sha256sum package</code>
<p><strong>10.4 </strong>Dependency information</p>
<fhead><strong>FILE:</strong> $(pwd)/nano</fhead>
<div class="file">
<p>DEPENDS=("")</p>
<p>CONFLICTS=("")</p>
</div>
<p>Dependency information is extremely important. It allows 'gpkg' to install any dependencies. It also warns the user when a package conflicts with another.</p>
<p>This should be fairly easy to figure out. Most projects will have this listed in their README. If you're the developer, you'll probably already know the dependencies your package requires.</p>
<p><strong>10.5 </strong>Source information</p>
<fhead><strong>FILE:</strong> $(pwd)/nano</fhead>
<div class="file">
<p>PACKAGE_SRC="https://nano-editor.org/dist/v7/nano-7.2.tar.xz</p>
<p>SOURCES=("nano-7.2.tar.xz" "nano-7.2"</p>
</div>
<p>PACKAGE_SRC shows Glacier where the sources for the program can be downloaded from.</p>
<p>SOURCES shows Glacier what PACKAGE_SRC downloads.</p>
<p><strong>9.6 </strong>Functions</p>
<fhead><strong>FILE:</strong> $(pwd)/nano</fhead>
<div class="file">
<p>getsource() {}</p>
<p>buildpkg() {}</p>
<p>installpkg() {}</p>
<p>installpkg_system() {}</p>
<p>removepkg() {}</p>
<p>removepkg_system() {}</p>
<p>updatepkg() {}</p>
<p>updatepkg_system() {}</p>
</div>
<p>Inside of the brackets, enter the commands that are needed to perform each function.</p>
<p>Anything prefixed with "system" refers to the use of 'syspkg'.</p>
</div>
<footer>
<p>Page last updated 9/17/24 @ 09:40</p>
<p>Page licensed under GNU Free Documentation License 1.3 or later</p>
<p>--------------------</p>
<p>Copyright (C) 2021-2023 Everest Linux</p>
<p>Linux (R) is a registered trademark of Linus Torvalds.</p>
<p>Everest Linux is provided AS IS, WITHOUT WARRANTY.</p>
</footer>