Alpine Package Keeper: Difference between revisions
No edit summary |
|||
Line 1: | Line 1: | ||
Because Alpine Linux is designed to run from RAM, package management involves two phases: | Because Alpine Linux is designed to run from RAM, package management involves two phases: | ||
* Installing / Upgrading / Deleting packages on a running system | * Installing / Upgrading / Deleting packages on a running system | ||
Line 10: | Line 8: | ||
This page documents the [http://git.alpinelinux.org/cgit/apk-tools.git apk tool] - See the [[Alpine_local_backup|Alpine Local Backup page]] for the lbu tool. | This page documents the [http://git.alpinelinux.org/cgit/apk-tools.git apk tool] - See the [[Alpine_local_backup|Alpine Local Backup page]] for the lbu tool. | ||
= Overview = | |||
The '''apk''' tool has the following applets: | The '''apk''' tool has the following applets: | ||
Line 54: | Line 53: | ||
|} | |} | ||
= Packages and Repositories = | |||
Software packages for Alpine Linux are digitally signed tar.gz archives containing the programs, configuration files, and dependency metadata. They have the extension "*.apk", and are often called "a-packs" | Software packages for Alpine Linux are digitally signed tar.gz archives containing the programs, configuration files, and dependency metadata. They have the extension "*.apk", and are often called "a-packs" | ||
Line 79: | Line 76: | ||
{{note|Currently there are no public https or ftp repositories. The protocols are available for local repositories}} | {{note|Currently there are no public https or ftp repositories. The protocols are available for local repositories}} | ||
= 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 <tt>/var/lib/apk</tt> or <tt>/etc/apk/cache</tt>. | 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 <tt>/var/lib/apk</tt> or <tt>/etc/apk/cache</tt>. | ||
Line 90: | Line 87: | ||
{{Tip|If using remote repositories, it is a good idea to do an '''update''' just before doing an '''add''' or '''upgrade''' command. That way you know you are using the latest software available}} | {{Tip|If using remote repositories, it is a good idea to do an '''update''' just before doing an '''add''' or '''upgrade''' command. That way you know you are using the latest software available}} | ||
= 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. | 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. | ||
Line 103: | Line 100: | ||
{{Note|Be careful when using third-party or the testing repository. Your system can go down.}} | {{Note|Be careful when using third-party or the testing repository. Your system can go down.}} | ||
= Remove a Package = | |||
Use '''del''' to remove a package (and dependencies that are no longer needed.) | Use '''del''' to remove a package (and dependencies that are no longer needed.) | ||
Line 110: | Line 106: | ||
apk del openssh openntp vim}} | apk del openssh openntp vim}} | ||
= Upgrade a Running System = | |||
To upgrade ''all'' the packages of a running system, use '''upgrade''' | To upgrade ''all'' the packages of a running system, use '''upgrade''' | ||
Line 125: | Line 120: | ||
}} | }} | ||
{{Note|Remember that when you reboot your machine, the remote repository will not be available until after networking is started. This means packages newer than your local boot media will likely not be installed after a reboot. | {{Note|Remember that when you reboot your machine, the remote repository will not be available until after networking is started. This means packages newer than your local boot media will likely not be installed after a reboot. To make an "upgrade" persist over a reboot, use a [[#Local Cache|local cache]].}} | ||
= Search for Packages = | |||
The '''search''' command searches the repository Index files for installable packages. | The '''search''' command searches the repository Index files for installable packages. | ||
Line 136: | Line 130: | ||
* To list all packages that list NTP as part of their description: {{cmd|apk search -v -d 'NTP' }} | * To list all packages that list NTP as part of their description: {{cmd|apk search -v -d 'NTP' }} | ||
= Info on Packages = | |||
The '''info''' command provides information on the contents of packages, their dependencies, and which files belong to a package. | The '''info''' command provides information on the contents of packages, their dependencies, and which files belong to a package. | ||
Line 185: | Line 179: | ||
/sbin/lbu is owned by alpine-conf-x.x-rx | /sbin/lbu is owned by alpine-conf-x.x-rx | ||
}} | }} | ||
= Additional apk Commands = | |||
In progress... | In progress... | ||
= Local Cache = | |||
{{:Local_APK_cache}} | {{:Local_APK_cache}} | ||
= 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: | 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: | ||
Line 207: | Line 198: | ||
will upgrade the entire system, keeping the asterisk package at the 1.6.0 or lower level | will upgrade the entire system, keeping the asterisk package at the 1.6.0 or lower level | ||
To later upgrade to the current version, | To later upgrade to the current version, | ||
{{cmd|apk add 'asterisk>1.6.1'}} | {{cmd|apk add 'asterisk>1.6.1'}} |
Revision as of 05:43, 8 December 2011
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.
This page documents the apk tool - See the Alpine Local Backup page for the lbu tool.
Overview
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 the 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 USB stick (/media/sda1) or CD-ROM (/media/cdrom), your repository file probably looks like this:
/media/sda1/apks/
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:
/media/sda1/apks http://dl-3.alpinelinux.org/alpine/v2.1/main https://dl-3.alpinelinux.org/alpine/v2.1/main ftp://dl-3.alpinelinux.org/alpine/v2.1/main
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/lib/apk or /etc/apk/cache.
apk update
fetch http://dl-3.alpinelinux.org/alpine/v2.1/main/APKINDEX.tar.gz
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 -U -X http://dl-3.alpinelinux.org/alpine/edge/testing/ --allow-untrusted
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 all the packages of a running system, use upgrade
apk update apk upgrade
To upgrade only a few packages, use the add command with the -u parameter:
apk update apk add -u busybox
Search for Packages
The search command searches the repository Index files for installable packages.
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:
apk search -v -d 'NTP'
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 is 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: 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
- The webpage where the application is hosted
- The size the package will require once installed (in bytes)
- What packages are required to use this one (depends)
- What packages require this one to be installed (required by)
- The contents of the package
- Any triggers this package sets. 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.
apk info --who-owns /sbin/lbu
will display/sbin/lbu is owned by alpine-conf-x.x-rx
Additional apk Commands
In progress...
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
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
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'