Logo

Note

Nearly everything here is a placeholder. You can suggest new features by opening a new issue on our codeberg.

Download

aerogel Linux is currently in development. Help us by contributing to anything!

About

aerogel Linux is a source-based Linux distribution based on KISS Linux, inspired by both Alpine Linux and Gentoo. It takes Alpine's philosophy of minimalism, security, and simplicity while embracing Gentoo's flexibility and source-driven approach.

Instead of forcing a fixed set of system components, aerogel lets you choose everything, from the init system to the libc implementation, and userland utilities. This makes it possible to craft a system that's tailored exactly to your needs, whether you want a lightweight server, a hardened workstation, or a desktop daily driver.

Philosophy

  • Simple by design - with sane defaults.
  • Configurable - without difficulty.
  • Lightweight - but not too lightweight.
  • Understandable - so you always know how your system works.
  • Secure - without any unnecessary restriction.
Loading packages...

Packages

This section contains several guides to set up specific applications on Aerogel Linux.

  • Audio, for recommended/supported audio software on Aerogel Linux.
  • Video, for video players and other misc things.
  • Desktops, for desktops and or Wayland Compositors/Window Managers.

Audio

Pipewire

Others

nothing!

PIPEWIRE!!!

Video

MPV

MPV!!

Info

MPV is too good. Be warned!

Warning

WOW!! WARNING!!

Bug

mpv is full of bugs.

Desktops

GNOME

GNOME!!

Development

This section will include many things relevant to contributing to Aerogel Linux, including but not limited to:

  • Using libgel
  • Creating packages
  • Domain-specific formats (commits, code preferences)

Making Packages

Note

If you're interested, we're looking for people who wanna package software for Aerogel Linux.

Packaging several software/libraries at once as a small team is pretty hard, so if you wanna help, feel free to open pull requests on our codeberg repo.

Aerogel Linux uses the KISS Linux package format for its packages.

New packages can be submitted at the Codeberg repository here.

Table of contents:

Structure/Files Used

The structure of a KISS Linux repository is organized as follows.

Note this example also includes optional files (you can see which files are optional below).

 git-repository/
└──  repo-name/
    └──  package-name/
        ├──  build
        ├──  checksums
        ├──  depends
        ├──  post-install
        ├──  pre-remove
        ├──  sources
        └──  version
FileLanguageSupports commentsSupports blank linesRequired
buildExecutablecheck
versionDSL
(see version)
closeAll lines (except the first) are ignored.check
checksumsDSL
(see checksums)
closecloseclose
(see checksums)
dependsDSL
(see depends)
checkcheckclose
sourcesDSL
(see sources)
checkcheckclose
pre-removeExecutableclose
post-installExecutableclose

build

The build file is an executable file used to build the package.

There are two arguments given to the build file:

  1. The destination directory (the installation "root"). Packages will be copied from here; e.g. you should do something such as make install PREFIX=$1/usr in the build file.
  2. The first field of the version file; e.g. if a version is 6.12.1 1, then $2 will be set to 6.12.1.

Example build file:

#!/bin/sh

./configure --prefix="/usr"

make
make DESTDIR="$1" install

version

The version file contains the package's version split into two fields: the package version, and the file version. The file version is ignored and is usually set to 1 across all packages.

As stated in Files Used, only the first line in the version file is read. All other lines are ignored.

Example version file:

6.12.1 1

These lines are ignored; only the first line of the `version` file is actually
read by the package manager.

checksums

The checksums file contains checksums for the files in the sources file (in the same order).

The checksums file is only necessary if the sources file contains a local file as a source.

Checksums can be generated by kiss, i.e. run:

root / # kiss checksum b3sum

to generate the checksums for the b3sum package.

An example checksum file can be found below (Disabling a checksum).

Disabling checksums

Danger

Disabling checksums is a security risk and can lead to corrupted or malicious files being installed on the user's system. This should never be done unless necessary.

To disable checksums, write SKIP in the appropriate line of the checksum file:

892a0875b9872acd04a9fde79b1f943075d5ea162415de3047c327df33fbaee5
8a5b38a76b778da8d6f4236f1ea89e680daea971be6ee3a57e4e7ae99a883aa2
SKIP

depends

The depends file contains a line-separated list of dependencies and make dependencies. To mark a dependency as a make dependency, put the word make after the dependency. Comments are also supported; begin a line with # for a comment.

Example depends file:

alsa-lib
meson make

# This is a comment.
wayland
wayland-protocols make

sources

The sources file contains a line-separated list of sources to pull files from.

Internet links must begin with either https:// or http://.

Git links must begin with git+, and can be suffixed with @BRANCH or #COMMIT, where BRANCH is a commit name and COMMIT is a commit ID.

Comments begin with a #.

Example sources file:

# This is a comment.
https://causal.agency/libretls/libretls-3.3.3p1.tar.gz libretls

# This is a path to a local file:
files/update-certdata.sh

# This is a git link:
git+https://github.com/kisslinux/kiss@dev

# This is a git link, but with a commit ID:
git+https://github.com/kisslinux/kiss#6b41497cc3dda673e5f92f669305bbe391c21f5f

pre-remove

pre-remove is an executable ran before a package is uninstalled, and can be used for doing manual pre-remove steps (or informing the user on how to do them).

Example pre-remove file:

#!/bin/sh

cat <<<EOF
This package (foo) stores very large logs in the directory /var/log/foo.
It is recommended to delete this directory after package removal.
EOF

post-install

post-install is an executable ran after a package is installed; this can be done to print information such as optional dependencies or do mandatory post-install steps.

Example post-install file:

#!/bin/sh -e

cat <<EOF

The commands zcat, unpigz and gunzip were merely symbolic
links to the pigz binary. They have been removed. To gain
them back, create the symlinks (or use an alias or shell
function).

EOF

More information

Package Style

This package style guide is based on the one made by KISS Community, with a few changes for readability, leniency, and slight differences between kiss and gel.

[0100]: Blacklisted Packages

The following package types are not allowed in the repository:

  • git packages
  • Obscure programs
  • Packages with known severe security vulnerabilities, unless there is a patch that fixes it.
  • Packages depending on systemd, unless there is a patch or service that removes the dependency.
  • Binaries for small programs

[0200]: Package Naming

Large packages with a large dependency count (especially Desktop Environments) should be given their own repository.

Binary packages should be suffixed with -musl-bin or -glibc-bin.

Packages should have all-lowercase names, and should avoid the characters +=/`.,?_ and all whitespace.

Shebang

When using a script, these rules must be followed.

[0300]: Formatting

Include a blank line below all shebangs:

#!/bin/sh -ex

# ...

[0400]: Compatibility

  • Always use #!/bin/sh as the build script shell.
  • The build, pre-remove, and post-install files must all pass through shellcheck with no warnings. Disable warnings if necessary.

[0500]: Error-checking

Use the -ex flags on shell shebang: #!/bin/sh -ex

Comments

The following guidelines should be followed when commenting in any package files.

[0800]: Grammar

Comments must use semi-formal grammar (avoid slang, but colloquialisms are allowed) and correct spelling, but are not required to have end punctuation (please use commas) nor a capital letter at the beginning.

# this is a comment

[0900]: Purpose

Comments should explain why something is being done, not what it is doing:

# `make install` doesnt create the directory
mkdir -p "$1/usr/bin"

Commit Messages

Commit messages must conform to the following rules.

[1000]: New Packages

Use the following commit message format when creating a package:

new package: [package] [version]

Use the following commit message format when updating a package:

[package]: update to [version]

[1100]: Commit Count

Each package should only have one commit on each modification (creation or updating). If a package requires corrections, the package should be rebased or have commits locally reversed and forcefully pushed.

Another possible option is having a maintainer close a pull request, recreate it locally with one commit message, and push it. If this route is taken, a comment such as "Manually merged in commit " should be written under the pull request.

Quotes

When quoting variables, the following rules should be followed.

[1200]: Only use quotes when necessary

Avoid using quotes when unnecessary:

# `build/bin/foo` does not need to be quoted
cp "build/bin/foo" "$1/usr/bin"

For reference, the above should be rewritten as:

cp build/bin/foo "$1/usr/bin"

[1300]: Quote formatting

Quote entire strings to insert a variable:

cp -f cat "$1/usr/bin/cat"

Unless it is being used to set a flag requiring an equals sign:

make DESTDIR="$1" install

Command Formatting

[1400]: Command Choice

Prefer cp and mkdir over install:

mkdir -p "$1/usr/bin"
cp ls "$1/usr/bin"

When using install, note the BSD syntax and GNU syntax differ.

[1500]: Directory formatting

Do not end directories in a slash.

# Bad:
cp foo "$1/usr/bin/"

# Good:
cp foo "$1/usr/bin"

[1600]: Build tool formatting

When using a command such as make, create a new line with \ if more than two variables or flags are being provided (excluding the operation itself).

Place the operation after the flags, unless you split the command across multiple lines.

# Bad:
make CC="$CC" DESTDIR="$1" PREFIX="/usr" install

# Good:
make install \
    CC="$CC" \
    DESTDIR="$1" \
    PREFIX="/usr"
# Bad:
meson build --no-tests

# Good:
meson --no-tests build
# Bad:
make all \
    ENABLE_FOO=yes \
    ENABLE_BAR=yes

# Good:
make ENABLE_FOO=yes ENABLE_BAR=yes no all