<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>
<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><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>
<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>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>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>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>'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>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>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>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>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>
