Alpine Package Keeper: Difference between revisions

From Alpine Linux
m (Bumped version numbers up to 2.6)
(41 intermediate revisions by 10 users not shown)
Line 1: Line 1:
= Alpine Linux Package Management =
<!--For searching: apk, APK-->


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
* Restoring a system to a previously configured state (e.g. after reboot), including all previously installed packages and locally modified configuration files.
* 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)'''
 
<br />
'''apk''' is the tool used to install, upgrade, or delete software on a running sytem
'''apk''' is the tool used to install, upgrade, or delete software on a running sytem.<br />
'''lbu''' is the tool used to capture the data necessary to restore a system to a previously configured state.
'''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|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:


*add - Add new packages to the running system
{|
*del - Delete packages from the running system
| [[#Add a Package|add]]
*fix - Attempt to repair or upgrade an installed package  
| Add new packages to the running system
*update - Update the index of available packages
|-
*info - Prints information about installed or available packages
| [[#Remove a Package|del]]
*search - Search for packages or descriptions with wildcard patterns
| Delete packages from the running system
*upgrade - Upgrade the currently installed packages
|-
*cache - Maintenance operations for locally cached package repository
| fix  
*version - Compare version differences between installed and available packages
| Attempt to repair or upgrade an installed package  
*index - create a repository index from a list of packages
|-
*fetch - download (but not install) packages
| [[#Update the Package list|update]]
*audit - List changes to the file system from pristine package install state
| Update the index of available packages
*verify - Verify a package signature
|-
| [[#Info on Packages|info]]
| Prints information about installed or available packages
|-
| [[#Search for Packages|search]]
| Search for packages or descriptions with wildcard patterns
|-
| [[#Upgrade a Running System|upgrade]]
| Upgrade the currently installed packages
|-
| [[#Cache Maintenance|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
|}


== Quickstart Guide ==
= Packages and Repositories =


=== 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 <code>.apk</code>, 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"
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 {{Path|APKINDEX.tar.gz}} to be considered a repository.


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 {{Path|/etc/apk/repositories}}, one repository per line. If you booted from USB stick ({{Path|/media/sda1}}) or CD-ROM ({{Path|/media/cdrom}}), your repository file probably looks something like this:


The '''apk''' utility can install packages from multiple repositories.  The list of repositories to check is stored in <tt>/etc/apk/repositories</tt>, one repository per line. If you booted from USB stick (<tt>/media/sda1</tt>) or CD-ROM (<tt>/media/cdrom</tt>), your repository file probably looks like this:
{{Cat|/etc/apk/repositories|/media/sda1/apks/}}
<pre>
/media/sda1/apks/
</pre>


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:
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:
<pre>
 
{{Cat|/etc/apk/repositories|
/media/sda1/apks
/media/sda1/apks
http://dl-3.alpinelinux.org/alpine/v1.10/packages/main
http://dl-3.alpinelinux.org/alpine/v2.6/main
https://dl-3.alpinelinux.org/alpine/v1.10/packages/extra
https://dl-3.alpinelinux.org/alpine/v2.6/main
ftp://ftp.alpinelinux.org/edge/packages/main
ftp://dl-3.alpinelinux.org/alpine/v2.6/main
</pre>
}}


{{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 - apk update ===
== Repository pinning ==


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>.
You can specify additional "tagged" repositories in {{Path|/etc/apk/repositories}}:


Example:
{{Cat|/etc/apk/repositories|
http://nl.alpinelinux.org/alpine/v2.6/main
@edge http://nl.alpinelinux.org/alpine/edge/main
@testing http://nl.alpinelinux.org/alpine/edge/testing
}}


'''apk update'''
After which you can "pin" dependencies to these tags using:
<pre>
fetch http://dl-3.alpinelinux.org/alpine/v1.10/packages/main/APKINDEX.tar.gz
fetch http://dl-3.alpinelinux.org/alpine/v1.10/packages/testing/APKINDEX.tar.gz
alpine 1.10.1 [/media/sda1/apks]
main v1.10.1-34-g977ff46 [http://dl-3.alpinelinux.org/alpine/v1.10/packages/main]
testing v1.10.0-32-gbf6b6cb [http://dl-3.alpinelinux.org/alpine/v1.10/packages/testing]
</pre>


{{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}}
{{cmd|apk add stableapp newapp@edge bleedingapp@testing}}


=== Add a Package - apk add ===
Apk will now by default only use the untagged repositories, but adding a tag to specific package:


Use '''add''' to install packages from a repository.  Any necessary dependencies are also installedIf you have multiple repositories, the '''add''' command installs the newest 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)
 
= 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 {{Path|APKINDEX.tar.gz}} from each repository and stores it in the local cache, typically {{Path|/var/lib/apk/}} or {{Path|/etc/apk/cache/}}.


Examples:
{{Cmd|apk update}}


'''apk add openssh'''
<!--
'''apk add openssh openntp vim'''
fetch http://dl-3.alpinelinux.org/alpine/v2.1/main/APKINDEX.tar.gz
-->


{{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.}}


=== Remove a Package -- apk del  ===
= Add a Package =


Use the '''del''' command to remove a package (and dependencies that are no longer needed.)  
Use '''add''' to install packages from a repository.  Any necessary dependencies are also installedIf you have multiple repositories, the '''add''' command installs the newest package.


{{Cmd|apk add openssh
apk add openssh openntp vim}}


'''apk del openssh'''
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 del openssh openntp vim'''


{{cmd|apk add cherokee --update-cache --repository http://dl-3.alpinelinux.org/alpine/edge/testing/ --allow-untrusted}}


= Anything below this marker is old =
{{Note|Be careful when using third-party or the testing repository. Your system can go down.}}


Removing packages is done using:
= Remove a Package  =
  % apk_delete openssh
Use '''del''' to remove a package (and dependencies that are no longer needed.)  


To remove a package plus it's dependencies, use:
{{cmd|apk del openssh
% apk_delete -R openssh
apk del openssh openntp vim}}


Even more dangerous is:
= Upgrade a Running System =
% apk_delete -r openssl
which will delete openssl plus all packages that depend on it.


Since removing packages (recursively) can seriously damage your system, it is best to use:  
To upgrade ''all'' the packages of a running system, use '''upgrade''':
% apk_delete -n openssh
Which will not really remove the package, but just show what it would do.


== Looking for packages? ==
{{cmd|apk update
apk upgrade
}}


To see the packages available in the repository, use:
To upgrade ''only a few'' packages, use the '''add''' command with the ''-u''/''--upgrade'' option:
% apk_fetch -l


Or you might use:
{{cmd|apk update
  % apk_fetch -l -v
apk add --upgrade busybox
Which will also show the version number of the available packages.
}}


If the text scrolls by too fast you can use:
{{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]].}}
% apk_fetch -l | less


== Info about your packages ==
= Search for Packages =
The '''search''' command searches the repository Index files for installable packages.


There are several other commands that give more information about the packages installed on your system.
Examples:
* To list all packages available, along with their descriptions: {{cmd|apk search -v}}
* To list all packages are part of the ACF system: {{cmd|apk search -v 'acf*' }}
* To list all packages that list NTP as part of their description, use the ''-d''/''--description'' option: {{cmd|apk search -v --description 'NTP' }}


To see the contents of a certain package, use:
= Info on Packages =
% apk_info -L openssh


To see the size of a package, use:
The '''info''' command provides information on the contents of packages, their dependencies, and which files belong to a package.
% apk_info -s openssh


To see all packages that depend on a package, eg zlib:
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.
% apk_glob -r zlib


To find out to what package a certain file or directory belongs to, eg /etc/shorewall:
Example: {{cmd|apk info -a zlib}}
% apk_info -W /etc/shorewall


== Upgrading alpine ==
'''zlib-1.2.5-r1 description:'''
A compression/decompression Library
'''zlib-1.2.5-r1 webpage:'''
<nowiki>http://zlib.net</nowiki>
'''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:'''


The easiest way to upgrade alpine is to safe your settings to floppy or usb-key and reboot using a new CD. But there are several other possibilities a well:
As shown in the example you can determine
* Change the CD, but do not reboot
* The '''description''' of the package (''-d''/''--description'')
* Update over network
* The '''webpage''' where the application is hosted (''-w''/''--webpage'')
* The '''size''' the package will require once installed (in bytes) (''-s''/''--size'')
* What packages are required to use this one  ('''depends''') (''-R''/''--depends'')
* What packages require this one to be installed ('''required by''') (''-r''/''--rdepends'')
* The '''contents''' of the package, that is, which files it installs (''-L''/''--contents'')
* Any '''triggers''' this package sets. (''-t''/''--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.


=== Changing the CD, no reboot ===
{{Tip|The '''info''' command is also useful to determine which package a file belongs to.  For example: {{cmd|apk info --who-owns /sbin/lbu}} will display


First update the package list:
  /sbin/lbu is owned by alpine-conf-x.x-rx
  % apk_fetch -u
}}


Check what packages have changed version numbers
= Additional apk Commands =
% apk_version -v
In progress...


Next:
= Local Cache =
% apk_version -v -l '<'
Will show you what packages needs to be updated


The first thing to check is whether the apk-tools need to be upgraded, if so, '''always''' do this first:
{{:Local_APK_cache}}
% apk_add -u apk-tools


Now it is time to upgrade the other packages:
= Advanced APK Usage =
% apk_version -q -l '<' | xargs apk_add -u


After your upgrade you might find some apk-new files in /etc,these are upgraded config files. A simple utility to go over these files is:
== Holding a specific package back ==
%  update-conf -l


=== Update over network ===
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:
{{cmd|1=apk add asterisk=1.6.0.21-r0}}
or
{{cmd|apk add 'asterisk<1.6.1'}}


This is about the same as the previous entry. The key-difference is that we will change the install-source for apk. This can be done in two ways, on the command-line, using ''export'' or changing an /etc file:
after which a {{cmd|apk upgrade}}


% export APK_PATH=http://dev.alpinelinux.org/alpine/v1.4/apks/
will upgrade the entire system, keeping the asterisk package at the 1.6.0 or lower level


or edit apk.conf, and add your requested resource.
To later upgrade to the current version,
% vi /etc/apk.conf


You can use sources from:
{{cmd|apk add 'asterisk>1.6.1'}}
* cdrom
* http(s)
* ftp
* rsync (remember that rsync has to be installed before you can use this! (''% apk_add rsync''))


After you made this change, continue as the cd-rom upgrade with, etc
[[Category:Package Manager]]
% apk_fetch -u

Revision as of 16:48, 4 August 2013


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 something like this:

Contents of /etc/apk/repositories

/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:

Contents of /etc/apk/repositories

/media/sda1/apks http://dl-3.alpinelinux.org/alpine/v2.6/main https://dl-3.alpinelinux.org/alpine/v2.6/main ftp://dl-3.alpinelinux.org/alpine/v2.6/main
Note: Currently there are no public https or ftp repositories. The protocols are available for local repositories.

Repository pinning

You can specify additional "tagged" repositories in /etc/apk/repositories:

Contents of /etc/apk/repositories

http://nl.alpinelinux.org/alpine/v2.6/main @edge http://nl.alpinelinux.org/alpine/edge/main @testing http://nl.alpinelinux.org/alpine/edge/testing

After which you can "pin" dependencies to these tags using:

apk add stableapp newapp@edge bleedingapp@testing

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)

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


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.

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 http://dl-3.alpinelinux.org/alpine/edge/testing/ --allow-untrusted

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.)

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/--upgrade option:

apk update apk add --upgrade busybox

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.

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, use the -d/--description option:

    apk search -v --description '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 (-d/--description)
  • The webpage where the application is hosted (-w/--webpage)
  • The size the package will require once installed (in bytes) (-s/--size)
  • What packages are required to use this one (depends) (-R/--depends)
  • What packages require this one to be installed (required by) (-r/--rdepends)
  • The contents of the package, that is, which files it installs (-L/--contents)
  • Any triggers this package sets. (-t/--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.
Tip: 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

Additional apk Commands

In progress...

Local Cache

Overview

To have the packages available during boot, apk can keep a cache of installed packages on a local disk.

Added 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.


Enabling Local Cache with current releases

Execute the script

setup-apkcache

and it will assist in enabling a local cache.

The script creates a symlink named /etc/apk/cache that points to the cache directory.

Tip: On a diskless installation, to make the disk where the cache directory is present be automatically mounted at boot you can 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.
Note: Custom shutdown commands were formerly added to a /etc/conf.d/local; but that method is now deprecated.



Special Caching Configurations

Enabling Local Cache on HDD installs

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

Manually create a cache dir and then symlink it to /etc/apk/cache:

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

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.


Manually Enabling Local Cache (required for releases prior to v2.3)

  1. Create a cache directory on the storage device where you keep the lbu backups (typically, /dev/sda1.)

    mkdir /media/sda1/cache

Tip: If you get an error that says "mkdir: can't create directory /media/usbdisk/cache: Read-only file system", then you probably need to remount your disk read-write temporarily. Try

mount -o remount,rw /media/sda1

and then don't forget to run

mount -o remount,ro /media/sda1

when you are done with the following commands
  1. Create a symlink to this directory from /etc/apk/cache.

    ln -s /media/sda1/cache /etc/apk/cache

  2. Run an lbu commit to save the change (/etc/apk/cache is in /etc and is automatically backed up.)

    lbu commit

Tip: If you needed to remount your disk read-write before, run

mount -o remount,ro /media/sda1

now that you are done with saving the changes

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.

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'