Gain insights into creating Alpine Linux packages. Delve into APKBUILDs, packaging basics, and repository management. Discover quality assurance and enhance your Alpine Linux and DevOps skills.

Doxx.tar.gz

In this course, you will learn how packaging software works in Alpine Linux, the most popular Docker Linux distribution.

You’ll first learn the basics: what is Alpine Linux and what are its advantages over other distributions, especially in a Docker environment? Next, you’ll cover the basics of packaging software: what are apk and APKBUILD, where should files be installed, and how can we create basic APKBUILDs and submit them for inclusion in Alpine Linux official repositories? You’ll also learn what makes an Alpine Linux package low or high quality. Finally, you’ll explore APKBUILDs for different programming languages and finish by creating your own private Alpine Linux repository with complex subpackages. 

By the end of the course, you will be able to create APKBUILDs which easily pass Alpine’s quality assurance. Overall, this course will increase your understanding of Alpine Linux and Linux in general and help you improve your DevOps skills.

Creating Alpine Linux Packages

## Preface

When using more than one Linux distribution, we notice that executables are almost always in `/usr/bin`, config files are in `/etc`, and so on. This is the work of the **Filesystem Hierarchy Standard (FHS)**, which standardizes the locations of different kinds of files across Linux distributions. This has multiple advantages:



* A program can predict where files are located. This can be very useful. For example, take a shell script that downloads an executable for us and installs it to our system. Thanks to the FHS, it can just assume that installing the executable to `/usr/local/bin` (the standard location for user-supplied executables) is acceptable and that it doesn't need special cases for different Linux distributions.


* A user can assume files are in well-known locations. This way, we don’t have to learn where specific files are all over again if we switch our Linux distribution.

## Why is this relevant to packaging?

Since Alpine Linux follows version 3.0 of the FHS, we have to make sure that newly created packages also follow this specification to pass Alpine Linux's quality assurance.

Most of the time, when we use `newapkbuild` to create a new `APKBUILD`, it will already pass all the suitable options to the respective build system to install all files in the correct directories. However, some build systems have wrong hardcoded paths or don't properly listen to the options passed to them. Due to this, proper knowledge of the FHS is required to verify that all files have been installed into the proper directory.

## `/bin`

`/bin` is the location of binaries that are critical for booting the system. An example of a package that installs its binaries to `/bin` is `openrc`, which manages service startup when booting Alpine Linux. Such binaries are installed to `/bin` to make it possible to boot the system without `/usr` mounted, in case it's on a separate partition or disk. Unless the package is required for booting, it's preferable to install binaries to `/usr/bin` instead.

## `/dev`

`/dev` is a temporary directory that contains the device node for files of each device (like a mouse, keyboard, etc.). Because `/dev` is a temporary directory that's emptied during shutdown, no package should be installed to `/dev`.

## `/etc`

`/etc` contains all configuration files that are editable by the system administrator. In contrast to all other directories mentioned here, `apk` will check if the files of a package in `/etc` have changed when installing a new version of a configuration file of that package to `/etc`. The old config file will be left in place, and the new file will be stored as `$FILENAME.apk.new`. This allows administrators to review the changes between the old and new configuration files.

## `/home`

`/home` is where user data is kept. No package should be installed to `/home` since `apk` is only meant to be a system package manager.

## `/lib`

`/lib` is the equivalent of `/bin` for libraries. An example of a package that installs to `/lib` is `musl`, since the C library is required for starting `openrc` during boot. The same rule as that for `/bin` applies here: unless a package really is necessary for booting the system, libraries should probably be installed to `/usr/lib` instead.

## `/media`

`/media` is the location where removable media like USB flash drives may be mounted. Packages shouldn't be installed in this directory.

## `/mnt`

`/mnt` is very similar to `/media` and is also used to mount temporarily connected partitions. The reason for having both `/media` and `/mnt` is that historically, `/mnt` was meant to be the temporary mount point for a single partition. In contrast, `/media` was meant to have subdirectories to contain multiple mount points (e.g., for a USB flash drive and a CD-ROM). In recent days, this distinction has mostly become obsolete. However, to keep compatibility, both directories are kept in place. As is the case for `/media`, packages shouldn’t be installed in this directory.

## `/opt`

`/opt` is meant as a place to install data that doesn't conform to the file hierarchy of the FHS. An example of a package installed in this directory is `electron`. Since it doesn't like having its binaries, libraries, and other files split amongst multiple folders, installing it to a subdirectory of `/opt` is a good option instead of cluttering other directories with various kinds of files.

## `/proc`

`/proc` is another temporary directory that's used by the kernel to expose information to the administrator (e.g., the current CPU frequency). Like `/dev`, packages shouldn't be installed in this directory.

## `/root`

`/root` is where the user data of the `root` user is kept. As such, no package should be installed in this directory either.

# Preface

When using more than one Linux distribution, we notice that executables are almost always in `/usr/bin`, config files are in `/etc`, and so on. This is the work of the **Filesystem Hierarchy Standard (FHS)**, which standardizes the locations of different kinds of files across Linux distributions. This has multiple advantages:



# Why is this relevant to packaging?

Since Alpine Linux follows version 3.0 of the FHS, we have to make sure that newly created packages also follow this specification to pass Alpine Linux's quality assurance.

Most of the time, when we use `newapkbuild` to create a new `APKBUILD`, it will already pass all the suitable options to the respective build system to install all files in the correct directories. However, some build systems have wrong hardcoded paths or don't properly listen to the options passed to them. Due to this, proper knowledge of the FHS is required to verify that all files have been installed into the proper directory.

# `/bin`

`/bin` is the location of binaries that are critical for booting the system. An example of a package that installs its binaries to `/bin` is `openrc`, which manages service startup when booting Alpine Linux. Such binaries are installed to `/bin` to make it possible to boot the system without `/usr` mounted, in case it's on a separate partition or disk. Unless the package is required for booting, it's preferable to install binaries to `/usr/bin` instead.

# `/dev`

`/dev` is a temporary directory that contains the device node for files of each device (like a mouse, keyboard, etc.). Because `/dev` is a temporary directory that's emptied during shutdown, no package should be installed to `/dev`.

# `/etc`

`/etc` contains all configuration files that are editable by the system administrator. In contrast to all other directories mentioned here, `apk` will check if the files of a package in `/etc` have changed when installing a new version of a configuration file of that package to `/etc`. The old config file will be left in place, and the new file will be stored as `$FILENAME.apk.new`. This allows administrators to review the changes between the old and new configuration files.

# `/home`

`/home` is where user data is kept. No package should be installed to `/home` since `apk` is only meant to be a system package manager.

# `/lib`

`/lib` is the equivalent of `/bin` for libraries. An example of a package that installs to `/lib` is `musl`, since the C library is required for starting `openrc` during boot. The same rule as that for `/bin` applies here: unless a package really is necessary for booting the system, libraries should probably be installed to `/usr/lib` instead.

# `/media`

`/media` is the location where removable media like USB flash drives may be mounted. Packages shouldn't be installed in this directory.

# `/mnt`

`/mnt` is very similar to `/media` and is also used to mount temporarily connected partitions. The reason for having both `/media` and `/mnt` is that historically, `/mnt` was meant to be the temporary mount point for a single partition. In contrast, `/media` was meant to have subdirectories to contain multiple mount points (e.g., for a USB flash drive and a CD-ROM). In recent days, this distinction has mostly become obsolete. However, to keep compatibility, both directories are kept in place. As is the case for `/media`, packages shouldn’t be installed in this directory.

# `/opt`

`/opt` is meant as a place to install data that doesn't conform to the file hierarchy of the FHS. An example of a package installed in this directory is `electron`. Since it doesn't like having its binaries, libraries, and other files split amongst multiple folders, installing it to a subdirectory of `/opt` is a good option instead of cluttering other directories with various kinds of files.

# `/proc`

`/proc` is another temporary directory that's used by the kernel to expose information to the administrator (e.g., the current CPU frequency). Like `/dev`, packages shouldn't be installed in this directory.

# `/root`

`/root` is where the user data of the `root` user is kept. As such, no package should be installed in this directory either.

# Why is this relevant to packaging?

Since Alpine Linux follows version 3.0 of the FHS, we have to make sure that newly created packages also follow this specification to pass Alpine Linux's quality assurance.

Most of the time, when we use `newapkbuild` to create a new `APKBUILD`, it will already pass all the suitable options to the respective build system to install all files in the correct directories. However, some build systems have wrong hardcoded paths or don't properly listen to the options passed to them. Due to this, proper knowledge of the FHS is required to verify that all files have been installed into the proper directory.

# `/bin`

`/bin` is the location of binaries that are critical for booting the system. An example of a package that installs its binaries to `/bin` is `openrc`, which manages service startup when booting Alpine Linux. Such binaries are installed to `/bin` to make it possible to boot the system without `/usr` mounted, in case it's on a separate partition or disk. Unless the package is required for booting, it's preferable to install binaries to `/usr/bin` instead.

# `/dev`

`/dev` is a temporary directory that contains the device node for files of each device (like a mouse, keyboard, etc.). Because `/dev` is a temporary directory that's emptied during shutdown, no package should be installed to `/dev`.

# `/etc`

`/etc` contains all configuration files that are editable by the system administrator. In contrast to all other directories mentioned here, `apk` will check if the files of a package in `/etc` have changed when installing a new version of a configuration file of that package to `/etc`. The old config file will be left in place, and the new file will be stored as `＄FILENAME.apk.new`. This allows administrators to review the changes between the old and new configuration files.

# `/home`

`/home` is where user data is kept. No package should be installed to `/home` since `apk` is only meant to be a system package manager.

# `/lib`

`/lib` is the equivalent of `/bin` for libraries. An example of a package that installs to `/lib` is `musl`, since the C library is required for starting `openrc` during boot. The same rule as that for `/bin` applies here: unless a package really is necessary for booting the system, libraries should probably be installed to `/usr/lib` instead.

# `/media`

`/media` is the location where removable media like USB flash drives may be mounted. Packages shouldn't be installed in this directory.

# `/mnt`

`/mnt` is very similar to `/media` and is also used to mount temporarily connected partitions. The reason for having both `/media` and `/mnt` is that historically, `/mnt` was meant to be the temporary mount point for a single partition. In contrast, `/media` was meant to have subdirectories to contain multiple mount points (e.g., for a USB flash drive and a CD-ROM). In recent days, this distinction has mostly become obsolete. However, to keep compatibility, both directories are kept in place. As is the case for `/media`, packages shouldn’t be installed in this directory.

# `/opt`

`/opt` is meant as a place to install data that doesn't conform to the file hierarchy of the FHS. An example of a package installed in this directory is `electron`. Since it doesn't like having its binaries, libraries, and other files split amongst multiple folders, installing it to a subdirectory of `/opt` is a good option instead of cluttering other directories with various kinds of files.

# `/proc`

`/proc` is another temporary directory that's used by the kernel to expose information to the administrator (e.g., the current CPU frequency). Like `/dev`, packages shouldn't be installed in this directory.

# `/root`

`/root` is where the user data of the `root` user is kept. As such, no package should be installed in this directory either.

Learn about the Filesystem Hierarchy Standard to understand what kind of files go where.

Introduction

Using abuild

Alpine's FHS

Creating Your First APKBUILD

Creating More Complex APKBUILDs

Hosting Our Own APK Repository

Additional APKBUILD Examples

Conclusion

What is the FHS?

Preface

Why is this relevant to packaging?