Alpine Linux package management
Because Alpine Linux is designed to run from RAM, package management involves two phases:
- Installing / Upgrading / Deleting packages on a running system.
- Restoring a system to a previously configured state (e.g. after reboot), including all previously installed packages and locally modified configuration files. (RAM-Based Installs Only)
apk is the tool used to install, upgrade, or delete software on a running sytem.
lbu is the tool used to capture the data necessary to restore a system to a previously configured state.
- 1 Overview
- 2 Packages and Repositories
- 3 Update the Package list
- 4 Add a Package
- 5 Add a local Package
- 6 Remove a Package
- 7 Upgrade a Running System
- 8 Search for Packages
- 9 Info on Packages
- 10 Additional apk Commands
- 11 Local Cache
- 12 To enable Local Cache on releases prior v2.3
- 13 Cache maintenance
- 14 Using the Local Cache with tmpfs volumes
- 15 Advanced APK Usage
The apk tool has the following applets:
|add||Add new 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|
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".
The packages are stored in one or more repositories. A repository is simply a directory with a collection of *.apk files. The directory must include a special index file, named APKINDEX.tar.gz to be considered a repository.
The apk utility can install packages from multiple repositories. The list of repositories to check is stored in /etc/apk/repositories, one repository per line. If you booted from a USB stick (/media/sda1) or CD-ROM (/media/cdrom), your repository file probably looks something like this:
In addition to local repositories, the apk utility uses busybox wget to fetch packages using http:, https: or ftp: protocols. The following is a valid repository file:
You can specify additional "tagged" repositories in /etc/apk/repositories:
After which you can "pin" dependencies to these tags using:
Apk will now by default only use the untagged repositories, but adding a tag to specific package:
1. will prefer the repository with that tag for the named package, even if a later version of the package is available in another repository
2. allows pulling in dependencies for the tagged package from the tagged repository (though it prefers to use untagged repositories to satisfy dependencies if possible)
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.|
Update the 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/.
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.
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.
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:
Note that multiple packages can be given. When installing a local package, all dependencies should also be specified. For example:
Remove a Package
Use del to remove a package (and dependencies that are no longer needed.)
Upgrade a Running System
To upgrade all the packages of a running system, use upgrade:
For example, the procedure on a system that has various repositories pinned might display as follows:
# apk update fetch http://dl-3.alpinelinux.org/alpine/v3.6/main/x86_64/APKINDEX.tar.gz fetch http://dl-3.alpinelinux.org/alpine/v3.6/community/x86_64/APKINDEX.tar.gz fetch http://dl-3.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz fetch http://dl-3.alpinelinux.org/alpine/edge/community/x86_64/APKINDEX.tar.gz fetch http://dl-3.alpinelinux.org/alpine/edge/testing/x86_64/APKINDEX.tar.gz v3.6.2-191-gf98d79930f  v3.6.2-190-ga5d68c47df  v3.6.0-4618-g0bf77c9821  v3.6.0-4605-g85ed51dd83  v3.6.0-4624-g11f1b9c8ab  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 a few packages, use the add command with the -u or --upgrade option:
Search for Packages
The search command searches the repository Index files for installable packages.
- To list all packages available, along with their descriptions:
- To list all packages are part of the ACF system:
- To list all packages that list NTP as part of their description, use the -d or --description option:
Info on Packages
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:
zlib-1.2.5-r1 description: A compression/decompression Library zlib-1.2.5-r1 webpage: http://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.
Listing installed packages
To list all installed packages, use:
To list all installed packages in alphabetical order, with a description of each, do:
apk -vv info|sort
Additional apk Commands
Alpine Linux needs to be able to pull packages from local media on boot. (You can't download packages from the net before you have a network connection.) Using remote repositories presents a problem. If the config files have been modified for a newer version of a package, and the older package is on local media, all sorts of fun can result.
The solution is a local cache of updated packages. This cache can be stored on any r/w media, typically the same location as the apkovl.
The cache is enabled by creating a symlink named /etc/apk/cache that points to the cache directory. Note that apk will ignore any cache residing on a tmpfs volume. If you want this for some reason, see section below on tmpfs caches.To enable local cache run:
To enable Local Cache on releases prior v2.3
Alpine Linux version prior to v2.3 does not have the setup-apkcache tool so the symlink needs to be set up manually.
To manually enable Local Cache on HDD install
If you've installed Alpine to your hard drive (as 'sys'), then create a cache dir and then an /etc/apk/cache symlink pointing to that dir:
You normally don't need apk cache on HDD 'sys' installs but it might be handy if you re-install from net to have the packages cached.
To manually enable Local Cache on run-from-RAM installs
- Create a cache directory on the device you store your lbu backups (typically,
- Create a symlink to this directory from
- Run an lbu commit to save the change (
/etcand is automatically backed up.)
- Done. Now whenever you run an apk command that pulls a new package from a remote repository, the package is stored on your local media. On startup, Alpine Linux will check the local cache for new packages, and will install them if available.
Over time, newer packages will replace older ones; the cache directory will contain all older versions of packages.
Delete old packagesTo clean out older versions of packages, run the clean command. or to see what is deleted
Download missing packagesIf you accidentally delete packages from the cache directory, you can make sure they are there with the download command,
Delete and download in one stepYou can combine the two steps into one with the sync command - this cleans out old packages and downloads missing packages.
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:
Using the Local Cache with 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 /cache.img /etc/apk/cache
- apk update
As per usual, if you want to download currently installed packages into the cache, use apk cache sync.
Advanced APK Usage
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:
orafter which a
will upgrade the entire system, keeping the asterisk package at the 1.6.0 or lower level
To later upgrade to the current version,