EverestLinux/everest-web
3
0
Fork 0
Code Issues 1 Pull Requests Projects Releases Wiki Activity

hi

Browse Source
This commit is contained in:
Liam Waldron
2024-02-01 08:48:40 -05:00
parent 4705d60122
commit aa61054d1d
12 changed files with 103 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
docs/dev-docs.html
View File

@@ -28,7 +28,8 @@
<h2>Developer Documentation</h2>
<p>This page contains developer-specific documentation.</p>
<h2>1 - Coding Style</h2>
<p><strong>1.1</strong> File Structure</p>
<p><strong>1.1</strong> C</p>
<p><i>1.1.1</i> File Structure</p>
<p>Files should follow this format:<p>
<ul>
<li>Header comment, including program name and LICENSE</li>
@@ -42,7 +43,7 @@
<p>Note that function declarations should be defined in a separate header, ex:</p>
<p><cil>#include "project_name.h"</cil></p>
<p>Indentations should be a single tab and be equal to 8 characters for better readability.</p>
<p><strong>1.2</strong> Functions</p>
<p><i>1.1.2</i> Functions</p>
<p>Functions should have their return type on one line, their name and parameters one line down, and the bracket one line under the name and arguments.</p>
<p>Example:</p>
<bigcodehead><strong>CODE:</strong> Proper function formatting in C</bigcodehead>
@@ -54,7 +55,7 @@
<p>}</p>
</div>
<p></p>
<p><strong>1.3</strong> Example Program</p>
<p><i>1.1.3</i> Example Program</p>
<fhead><strong>FILE:</strong> prog.c</fhead>
<div class="file">
<p>#include &lt;stdio.h&gt;</p>
@@ -83,6 +84,31 @@
<p>&nbsp;<p>
<p>#endif</p>
</div>
<p><i>1.1.4</i> common.h</p>
<p>For large programs which include many header files, it is perfectly acceptable to define these includes in a separate header and then include that in each file.</p>
<fhead><strong>FILE:</strong> common.h</fhead>
<div class="file">
<p>#ifndef COMMON_H_</p>
<p>#define COMMON_H_</p>
<p>&nbsp;</p>
<p>#include &lt;color.h&gt;</p>
<p>#include &lt;stdio.h&gt;</p>
<p>#include &lt;unistd.h&gt;</p>
<p>&nbsp;</p>
<p>#endif</p>
</div>
<p></p>
<fhead><strong>FILE:</strong> prog.c</fhead>
<div class="file">
<p>#include "common.h"</p>
<p>&nbsp;</p>
<p>int</p>
<p>main()</p>
<p>{</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;printf("hello\n");
<p>}</p>
</div>
<p><strong>1.2</strong> Bash/Shell</p>
<h2>2 - Licensing</h2>
<p><strong>2.1</strong> Disclaimer</p>
<warnhead><strong>WARNING:</strong></warnhead>

51
docs/intro-to-glacier.html
View File

@@ -36,15 +36,19 @@
<p>A system profile describes your base system, including C library, architecture, SELinux support, multilib support, etc.</p>
<h2>3 - Included programs</h2>
<p><strong>3.1 </strong>gpkg</p>
<p>'gpkg' is the program most users will be interacting with. It handles the downloading, installation, and logging of packages.</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>'syspkg' is like 'gpkg', except it operates on the system index, rather than the local index. End users should not use this unless instructed to.</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>'glist' lists all installed packages, allowing the user to filter by name.
<p><cil>glist</cil> lists all installed packages, allowing the user to filter by name.
<p><strong>3.4 </strong>gquery</p>
<p>'gquery' queries information on a package.</p>
<p><strong>3.5 </strong>glacier-mkprofile</p>
<p>'glacier-mkprofile' makes changes to the system-wide profile. Users should not interact with this unless needed.</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>4 - Frontends</h2>
<p>Frontends, or wrappers, may provide additional functionality to Glacier.</p>
<warnhead><strong>WARNING:</strong></warnhead>
@@ -54,36 +58,35 @@
<h2>5 - Merging packages</h2>
<p><strong>5.1 </strong>Using gpkg</p>
<p>To merge a package from a repository:</p>
<code>(root)# gpkg -f repo/pkg</code>
<p>For instance, to install 'vim' in the 'world' repository:</p>
<code>(root)# gpkg -f world/vim</code>
<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 'syspkg' 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 'syspkg' anyways, you are acknowledging that things may break.</p>
<p>To merge a package from a repository:</p>
<code>(root)# syspkg -f repo/pkg</code>
<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>6 - 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 'pkgname.old'.</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 repo/pkg</code>
<code>(root)# gpkg -u pkg</code>
<p><strong>6.3 </strong>Using syspkg</p>
<p>As mentioned above, 'syspkg' is intended for system development, and NOT for end users.</p>
<p>However, 'syspkg -u' has some use cases for end users. These include:</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 repo/pkg</code>
<code>(root)# syspkg -u pkg</code>
<h2>7 - 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 'pkgname.rm'. This means it will be wiped after the next reboot.</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>Note that no repository name was provided. It is not required, as no files will be downloaded during the removal process.</p>
<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>
@@ -98,20 +101,20 @@
<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 'gpkg -d'</li>
<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 'gpkg -fl pkg'</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 'x86-musl', the new repository should offer packages compatible with 'x86-musl'.</p>
<p>Ensure the repository you wish to migrate to supports your system profile. For example, if your profile is <cil>x86-musl</cil>, the new repository should offer packages compatible with <cil>x86-musl</cil>.</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 'GREPO' variable in '/etc/glacier.conf':</p>
<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>

21
docs/meta-reading.html
View File

@@ -29,7 +29,7 @@
<p>Documentation for Everest is formatted in a specific way. This page explains how a page is formatted, and what certain things mean, in as much detail as possible.</p>
<h2>2 - Cards</h2>
<p><strong>2.1 </strong>Introduction</p>
<p>Most Everest documentation pages will contain some type of a "card". Put simply, these are small sections that contain file contents, kernel configurations, warnings, notes, etc. There are 6 types of cards:</p>
<p>Most Everest documentation pages will contain some type of a "card". Put simply, these are small containers that contain file contents, kernel configurations, warnings, notes, etc. There are 6 types of cards:</p>
<p><strong>2.2 </strong>Note</p>
<p>This card is the most simple. It contains a note on a certain section. They are usually not required to read, but contain important information.</p>
<notehead><strong>NOTE:</strong></notehead>
@@ -72,9 +72,26 @@
<div class="news">
<p>This is an example of a news card.</p>
</div>
<h2>3 - Page Structure</h2>
<p>Everest documentation pages are organized into:</p>
<ul>
<li><a>Chapters</a></li>
<li><a>Sections</a></li>
<li><a>Subsections</a></li>
</ul>
<p><strong>3.1</strong> Chapters</p>
<p>Chapters are typically the largest sections on a given page. The topics they cover are very broad. Each chapter contains its own sections.</p>
<p>A chapter header is large, bold, has a colored sidebar, and is denoted by its number.</p>
<p><strong>3.2</strong> Sections</p>
<p>Sections are nested within chapters, and typically pertain to more specific topics related to a chapter.</p>
<p>A section header is bold, and is denoted by the number of the chapter it is nested under, followed by that section's number.</p>
<p><strong>3.3</strong> Subsections</p>
<p>Subsections are nested within sections, and usually contain very specific topics pertaining to a section (and chapter at large). Sometimes, a page does not use subsections at all.</p>
<p>A subsection header is italic, and is denoted by the number of the chapter it is nested under, followed by the number of the section it is nested under, followed by that subsection's number.</p>
</div>
<footer>
<p>Page last updated 12/07/2023 @ 12:06</p>
<p>Page last updated 1/08/2024 @ 17:28</p>
<p>Page licensed under GNU Free Documentation License 1.3 or later</p>
<p>--------------------</p>
<p>Copyright (C) 2021-2023 Everest Linux</p>

2
docs/recovery.html
View File

@@ -26,7 +26,7 @@
Back to home
</button>
<h2>Recovery</h2>
<p>System security is very important, however there are time that a system becomes so secure that the owner of the system becomes locked out of their own computer. There are a couple different methods for recovering a locked system.</p>
<p>System security is very important, however there are times when a system becomes so secure that the owner of the system becomes locked out of their own computer. There are a couple different methods for recovering a locked system.</p>
<h2>1 - Issues</h2>
<p><strong>1.1</strong> Issues resulting in a locked system</p>
<p>There are many things which may lock someone out of their system. The most notable ones are:</p>