Alpine Package Keeper

This page documents the Alpine Package Keeper(APK), the package manager in Alpine Linux. Refer to the excellent guide Working with apk from Alpine Linux Documentation project to learn the basics.

For diskless systems, package management requires Alpine Local Backup Utility (lbu), which captures the data necessary to restore a system to a previously configured state.

Note: It is vital for users of Alpine Linux to have a basic understanding on repositories and release branches to use apk.

Overview

The apk-tools provides apk and it supports the following operations:

add	Add new packages or upgrade packages to the running system
del	Delete packages from the running system
fix	Attempt to repair or upgrade an installed package
update	Update the index of available packages
info	Prints information about installed or available packages
search	Search for packages or descriptions with wildcard patterns
upgrade	Upgrade the currently installed packages
cache	Maintenance operations for locally cached package repository
version	Compare version differences between installed and available packages
index	create a repository index from a list of packages
fetch	download (but not install) packages
audit	List changes to the file system from pristine package install state
verify	Verify a package signature
dot	Create a graphviz graph description for a given package
policy	Display the repository that updates a given package, plus repositories that also offer the package
stats	Display statistics, including number of packages installed and available, number of directories and files, etc.
manifest	Display checksums for files contained in a given package

Packages and Repositories

Software packages for Alpine Linux are digitally signed tar.gz archives containing programs, configuration files, and dependency metadata. They have the extension .apk, and are often called "a-packs". All packages from Alpine Linux team are organized into three official repositories. Technically, any directory with a collection of *.apk files with a special index file, named APKINDEX.tar.gz can be considered a repository, albeit a personal repository.

Update Package list

Remote repositories change as packages are added and upgraded. To get the latest list of available packages, use the update command. The command downloads the APKINDEX.tar.gz from each repository and stores it in the local cache, typically /var/cache/apk/, /var/lib/apk/ or /etc/apk/cache/.

apk update

Adding the --update-cache, or for short -U switch to another apk command, as in apk --update-cache upgrade or apk -U add ..., the command has the same effect as first running apk update before the other apk command.

Tip: With remote repositories, it is a good idea to always do an update right before doing an upgrade or add command. That way the command will install the latest available packages.

Add a Package

Use add to install packages from a repository. Any necessary dependencies are also installed. If you have multiple repositories, the add command installs the newest package.

apk add openssh apk add openssh openntp vim

If you only have the main repository enabled in your configuration, apk will not include packages from the other repositories. To install a package from the edge/testing repository without changing your repository configuration file, use the command below. This will tell apk to use that particular repository.

apk add cherokee --update-cache --repository https://dl-cdn.alpinelinux.org/alpine/edge/testing/ --allow-untrusted

Note: Be careful when using third-party or the testing repository. Your system can go down.

Add a local Package

To install a locally available apk package, for example if this device has no internet access but you can upload apk packages directly to it, use the --allow-untrusted flag:

apk add --allow-untrusted /path/to/file.apk

Note that multiple packages can be given. When installing a local package, all dependencies should also be specified. For example:

apk add --allow-untrusted /var/tig-2.2-r0.apk /var/git-2.11.1-20.apk

Remove a Package

Use del to remove a package (and dependencies that are no longer needed.)

apk del openssh apk del openssh openntp vim

Upgrade a Running System

To upgrade Alpine Linux to a newer release branch refer Upgrading Alpine. To get the latest security upgrades and bugfixes available for the currently installed release branch of a running system, there are two steps:

• update the list of available packages
• upgrade the installed packages:

apk update apk upgrade

Or, combining the same into one single command:

apk -U upgrade

Here is an example, showing the procedure on a system that has several additional repositories pinned:

 # apk update
 fetch https://dl-3.alpinelinux.org/alpine/v3.6/main/x86_64/APKINDEX.tar.gz
 fetch https://dl-3.alpinelinux.org/alpine/v3.6/community/x86_64/APKINDEX.tar.gz
 fetch https://dl-3.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
 fetch https://dl-3.alpinelinux.org/alpine/edge/community/x86_64/APKINDEX.tar.gz
 fetch https://dl-3.alpinelinux.org/alpine/edge/testing/x86_64/APKINDEX.tar.gz
 v3.6.2-191-gf98d79930f [https://dl-3.alpinelinux.org/alpine/v3.6/main]
 v3.6.2-190-ga5d68c47df [https://dl-3.alpinelinux.org/alpine/v3.6/community]
 v3.6.0-4618-g0bf77c9821 [https://dl-3.alpinelinux.org/alpine/edge/main]
 v3.6.0-4605-g85ed51dd83 [https://dl-3.alpinelinux.org/alpine/edge/community]
 v3.6.0-4624-g11f1b9c8ab [https://dl-3.alpinelinux.org/alpine/edge/testing]
 OK: 20118 distinct packages available
 
 # apk upgrade
 (1/2) Upgrading extra-cmake-modules@testing (5.38.0-r0 -> 5.39.0-r0)
 (2/2) Upgrading extra-cmake-modules-doc@testing (5.38.0-r0 -> 5.39.0-r0)
 Executing mdocml-apropos-1.14.1-r0.trigger
 OK: 2635 MiB in 803 packages

To upgrade only specific packages, use the upgrade command and specify them:

apk update apk upgrade busybox

To enable unattended, automatic upgrades of packages, see the apk-autoupdate package.

Upgrading "diskless" and "data" disk mode installs

If booting a "diskless" system from a read-only device, or iso image on writable media, it's not possible to update the boot files (kernel, modules, firmware, ...) that reside on that device.

It becomes possible to update the boot files, though, if using a boot device that is writable and has been prepared with setup-bootable.

However, even then, the kernel, with its modules and firmware files, can still not be updated directly through regular packages updates. Instead, there is the update-kernel script that can generate initfs images and install them together with upgraded kernels.

Upgrading can be done as follows.

apk add mkinitfs

This package is required for the generation of the initial filesystem used during boot.

• Additional initfs features that are missing in the default configuration, like the btrfs filesystem support (at the time of writing, to allow loading .apkovl configs and package cache during boot), may be enabled in /etc/mkinitfs/mkinitfs.conf.
• Available initfs features may be listed with ls /etc/mkinitfs/features.d

ls /etc/mkinitfs/features.d apk add nano nano /etc/mkinitfs/mkinitfs.conf lbu commit

Finally update the kernel and its boot environment.

update-kernel /media/sdXY/boot/

• An update-kernel run needs at least 8 GB free ram memory to avoid a broken modloop-image.
• See update-kernel --help for options to manually add additional module or firmware packages.

Search for Packages

The search command searches the repository Index files for installable packages.

The return format is Package-Version. Omit Version for apk add Package

Examples:

• To list all packages available, along with their descriptions:

  apk search -v

• To list all packages are part of the ACF system:

  apk search -v 'acf*'

• To list all packages that list NTP as part of their description, use the -d or --description option:

  apk search -v --description 'NTP'

apk info

The info command provides information on the contents of packages, their dependencies, and which files belong to a package.

For a given package, each element can be chosen (for example, -w to show just the webpage information), or all information displayed with the -a command.

Example:

apk info -a zlib

zlib-1.2.5-r1 description:
A compression/decompression Library

zlib-1.2.5-r1 webpage:
https://zlib.net

zlib-1.2.5-r1 installed size:
94208

zlib-1.2.5-r1 depends on:
libc0.9.32

zlib-1.2.5-r1 is required by:
libcrypto1.0-1.0.0-r0
apk-tools-2.0.2-r4
openssh-client-5.4_p1-r2
openssh-5.4_p1-r2
libssl1.0-1.0.0-r0
freeswitch-1.0.6-r6
atop-1.25-r0 

zlib-1.2.5-r1 contains:
lib/libz.so.1.2.5
lib/libz.so.1
lib/libz.so 

zlib-1.2.5-r1 triggers:

As shown in the example you can determine

• The description of the package (-d or --description)
• The webpage where the application is hosted (-w or --webpage)
• The size the package will require once installed (in bytes) (-s or --size)
• What packages are required to use this one (depends) (-R or --depends)
• What packages require this one to be installed (required by) (-r or --rdepends)
• The contents of the package, that is, which files it installs (-L or --contents)
• Any triggers this package sets. (-t or --triggers) Listed here are directories that are watched; if a change happens to the directory, then the trigger script is run at the end of the apk add/delete. For example, doing a depmod once after installing all packages that add kernel modules.

Check file ownership

The info command is also useful to determine which package a file belongs to. For example:

apk info --who-owns /sbin/lbu

will display

/sbin/lbu is owned by alpine-conf-x.x-rx

Check Dependencies

The info command specific to check package dependency and reverse dependency is explained below:

The option -R or --depends lists the dependencies of the package.

apk info --depends pipewire

pipewire-1.0.6-r1 depends on:
/bin/sh
so:libc.musl-x86_64.so.1
so:libpipewire-0.3.so.0

The option -r or --rdepends lists the reverse dependencies of the package (all other packages which depend on the package).

apk info --rdepends pipewire

pipewire-1.0.6-r1 is required by:
xdg-desktop-portal-wlr-0.7.1-r0
pipewire-pulse-1.0.6-r1

Listing installed packages

To list all installed packages, use:

apk info

To list all installed packages in alphabetical order, with a description of each, do:

apk -vv info

The apk tool does not have a subcommand to list manually-installed packages that do not have reverse dependencies. To get this information on a traditional system that is not using lbu, try this script. Note that this approach will also list core packages like alpine-base that should not be removed.

#!/bin/sh
apk info | grep -ve '-doc$' | sort | while read pkg
        do
                rdep=`apk info -qr "$pkg"`
                [ -z "$rdep" ] && echo $pkg
        done

apk dot

The dot option renders package dependencies as graphviz graphs. To view the dependencies of a package graphically using apk and Graphviz, you can use dot option to generate a dependency graph in DOT format, which can then be visualized using Graphviz tools like dot.

apk dot package

For example:

$ apk dot busybox
digraph "apkindex" {
  rankdir=LR;
  node [shape=box];
  "busybox-1.36.1-r29" -> "musl-1.2.5-r0"[arrowhead=inv,label="so:libc.musl-x86_64.so.1",];
}

Here’s a step-by-step guide to use this tool, along with the sample output given at the final step :

Generate dot file

Use the apk command with the dot option to generate the dependency graph for the desired package, as shown above and save the output to a dot file.

$ apk dot seatd > seatd_dependencies.dot

Convert to Image Format

Use Graphviz to convert the DOT file into a graphical format such as PNG, PDF, or SVG. For example, to convert the DOT file to a PNG image, run:

$ dot -Tpng seatd_dependencies.dot -o seatd_dependencies.png

You can also use other output formats supported by Graphviz by changing the -T option (e.g., -Tpdf for PDF, -Tsvg for SVG).

View the Dependency Graph

Seatd dependencies

Open the generated image file with an image viewer of your choice to view the dependency graph.

$ swayimg seatd_dependencies.png 

apk policy

To display the repository a package was installed from and will be updated from, plus any tagged or enabled repositories where it is also offered, if any, for this architecture - its policy:

apk policy package

For example:

 $ apk policy vlc
 vlc policy:
  2.2.6-r1:
    lib/apk/db/installed
    https://dl-3.alpinelinux.org/alpine/v3.7/community
  3.0.0_rc2-r1:
    @edgecommunity https://dl-3.alpinelinux.org/alpine/edge/community

Local Cache

Overview

APK can keep a cache of installed packages on a local disk.

In diskless installations, since these packages are available during boot, packages can then be automatically (re-)installed from local media into RAM when booting, without requiring, and even before there is a network connection. The cache can be stored on any writable media, or at the same location as the .apkovl file from the local backup utility lbu.

HDD or sys mode installs don't need an apk cache to maintain their state, it still allows to serve packages over the network, though, e.g. to get installed by other local machines.

Enabling Local Cache

Execute the script setup-apkcache will assist in enabling a local cache. The script creates a symlink named /etc/apk/cache that points to the cache directory.

setup-apkcache

Cache can also be manually enabled by creating a cache dir and then symlink it to /etc/apk/cache:

mkdir -p /var/cache/apk ln -s /var/cache/apk /etc/apk/cache

On a diskless installation, to make the disk where the cache directory is present be automatically mounted at boot create an empty file .boot_repository inside the cache directory.

Cache maintenance

Removing older packages

When newer packages are added to the cache over time, the older versions of the packages default to remain in the cache directory.

The older versions of packages can be removed with the clean command.

apk cache clean

Or to see what is deleted include the verbose switch:

apk -v cache clean

Download missing packages

If you accidentally delete packages from the cache directory, you can make sure they are there with the download command,

apk cache download

Delete and download in one step

You can combine the two steps into one with the sync command - this cleans out old packages and downloads missing packages.

apk cache -v sync

Automatically Cleaning Cache on Reboot

To automatically attempt to validate your cache on reboot, you can add the above command to a /etc/local.d/*.stop file:

Contents of /etc/local.d/cache.stop

#!/bin/sh # verify the local cache on shutdown apk cache -v sync # We should always return 0 return 0

Tip: Usually the only time you need to reboot is when things have gone horribly wrong; so this is a "best effort" to cover forgetting to sync the cache; It is much better to run sync immediately after adding or upgrading packages.

Local Cache on tmpfs volumes

In some circumstances it might be useful to have the cache reside on tmpfs, for example if you only wish for it to last as long as the system is up.

NOTE: apk is coded to ignore tmpfs caches, and this is correct behaviour in most instances. Using tmpfs as a package cache can consume large amounts of system memory if you install a lot of packages, possibly resulting in a crashed system. You can limit this by restricting the size of your cache to a small number (128M in the example below).

To do it, you need to create an image inside which your cache can live. We do this by creating an image file, formatting it with ext2, and mounting it at /etc/apk/cache.

apk add e2fsprogs dd if=/dev/zero of=/apkcache.img bs=1M count=128 mkfs.ext2 -F /apkcache.img mkdir -p /etc/apk/cache mount -t ext2 /apkcache.img /etc/apk/cache apk update

As usual, if you want to download currently installed packages into the cache, use apk cache sync.

Advanced APK Usage

Commandline repository options

By default, the apk utility will use the system repositories for all operations. This behavior can be overridden by the following options:

--repositories-file REPOFILE	Override the system repositories by specifying a repositories file.
-X|--repository REPO	Specify a supplemental repository that will be used in addition to the system repositories. This option can be provided multiple times.

Holding a specific package back

In certain cases, you may want to upgrade a system, but keep a specific package at a back level. It is possible to add "sticky" or versioned dependencies. For instance, to hold the asterisk package to the 1.6.2 level or lower:

apk add asterisk=1.6.0.21-r0

or

apk add 'asterisk<1.6.1'

after which a

apk upgrade

will upgrade the entire system, keeping the asterisk package at the 1.6.0 or lower level

To later upgrade to the current version,

apk add 'asterisk>1.6.1'

will ensure that 1.6.1 is the minimum version used.

You can also use "fuzzy" version matching to pin the version to a major/minor release. For example:

apk add 'asterisk=~1.6'

will match any version of asterisk that starts with 1.6 (such as 1.6.0.21-r0 or 1.6.9.31-r9) <ref>Alpine source commit message</ref>

If you desire deterministic, repeatable package installation (such as with containerized environments) via package pinning, it is important to understand your package repo's version retention rules. For example, most Alpine package repos contain an "edge" branch, which may drop package versions that are not deemed fit to make it into a stable branch. This means that pinning to a version on the edge branch may stop working after the package version is revoked from the repo. Always pin to a package version that is intended for your current Alpine Linux version.

Commit hooks

If you'd like to trigger an action or run a certain script on every commit made by apk, there's a built-in method for that. On every commit apk looks for executables located in the "/etc/apk/commit_hooks.d/" directory, and executes them both before and after the commit. To provide some way to selectively run hooks either before or after a change is commited by apk, the scripts are called with "pre-commit" or "post-commit" as argument 1. This is an example of a hook to do different things before and after commit:

#!/bin/sh if [ "$1" = "pre-commit" ]; then do_something elif [ "$1" = "post-commit" ]; then do_something_else fi

Commit hooks are $PATH-aware, so for the sake of security it's recommended to specify absolute paths to executables.

Rosetta Stone

Rosetta Stone or a Comparison chart shows how standard things related to package management are done in Alpine Linux compared to other popular distributions.

Troubleshooting

"apk-tools is old"

apk update, apk upgrade or apk add may report the following:

WARNING: This apk-tools is OLD! Some packages might not function properly

This may happen if you are running Alpine Linux stable version with a certain edge/main, edge/community or testing package(s) also installed. One resolution is to consider upgrading apk-tools. If edge is already tagged in your repositories, then try:

apk add --upgrade apk-tools@edge

ERROR: UNTRUSTED signature

This happens when the release version changes. You need to update the local apk keys.

If you have already updated your repositories, allow them to update without the trusted key:

apk update --allow-untrusted

Then install the keys upgrade:

apk fix --upgrade --allow-untrusted alpine-keys

Now updates and upgrades should proceed normally.

Alternative, the updated alpine-keys package may be obtained, verified, installed directly, as covered earlier, prior to a repository update.

Other Related articles

• Comparison with other distros
• Upgrading Alpine Linux to newer Release Branch
• Understand Repositories in Alpine Linux

External Links

• 10 Alpine Linux apk Command Examples Vivek Gite 2019