Alpine Linux - User contributions [en]

Release Notes for Alpine 3.21.0

2024-10-16T11:46:10Z

Newbyte: Add note about linux-firmware now being compressed

== Highlights ==

* Go 1.23.1
* Rust 1.81
* GNOME 47
* KDE Plasma 6.1.5
* LXQt 2.0.0
* GCC 14.2.0

== OpenSSH ==

{{Note|TODO: Remove this section if https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68589 gets merged before 3.21 is released }}

You need to restart your sshd service!

Since the <code>9.8_p1</code> release, openssh-server is now split into two binaries, sshd and sshd-session. With this change sshd needs to be restarted to be able to accept new connections.

Since managing services has always been out-of-scope for apk, we will NOT do the following for you:

<code>
rc-service --ifstarted sshd restart
</code>

== GNOME 47 ==

GNOME 47 made it into Alpine 3.21. Everything should work as expected. Make sure you read the GNOME 47 release notes: https://release.gnome.org/47/

== LXQt 2.0.0 ==

LXQt has been updated to release 2.0.
* It now uses Qt6
* Many parts of LXQt are now wayland ready¹, but wayland ports of the following are pending: {{pkg|screengrab}}, {{pkg|lxqt-globalkeys}}, LXQt Panel's task-bar² and keyboard indicator, some input settings, and settings of monitor, power button, and screen locker.
* LXQt Panel has a new default application menu called Fancy Menu.
¹ [https://github.com/lxqt/lxqt-wayland-session lxqt-wayland-session] has not been released or packaged yet, but most folks wanting to test on wayland will want to use it. 
² Most folks testing LXQt on wayland are using {{pkg|waybar}} temporarily until the task-bar is ported.

== Jellyfin ==

Jellyfin now uses the recommended fork of ffmpeg called <code>jellyfin-ffmpeg</code> by default. If you want to change that, take a look at the <code>ffmpegpath</code> variable in <code>/etc/conf.d/jellyfin</code>. ([https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69924 !69924])

== Bats ==

"main/bats" was renamed to "main/bats-core". Now there is a meta package "community/bats" which contains:

* bats-core
* bats-file
* bats-support
* bats-assert

== ISC DHCP ==

{{Note|TODO: Write something cool if https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70974 (or alternative) is merged }}

== linux-firmware ==

linux-firmware is now compressed with ZSTD compression. If you run a custom built Linux kernel, you need to ensure that <code>CONFIG_FW_LOADER_COMPRESS_ZSTD=y</code> is set in your configuration.

Release Notes for Alpine 3.20.0

2024-05-11T10:44:51Z

Newbyte: /* GNOME 46 */ Add note about breaking change

== Base System ==

=== grub 2.12 ===

When upgrading existing installations using grub on UEFI systems, make sure to update the installed bootloader before rebooting, otherwise your machine might not boot.

The problem is that grub added new configuration that executes <code>fwsetup --is-supported</code>. The problem is that grub 2.06 does not supported the <code>--is-supported</code> argument yet, causing grub to unconditionally try to reboot into firmware.

Here is an example assuming the default setup. Don't blindly copy this examples but verify what's applicable to your system.

==== EFI ====

{{Cmd|
# grub-install --target{{=}}<var>$target</var> --efi-directory{{=}}<var>$efi_directory</var> \
--bootloader-id{{=}}alpine --boot-directory{{=}}/boot --no-nvram
# install -D <var>$efi_directory</var>/EFI/alpine/grub<var>$fwa</var>.efi <var>$efi_directory</var>/EFI/boot/boot<var>$fwa</var>.efi

}}

; target : The relevant [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 target] for your system
; efi_directory : Either {{Path|/boot/efi}} or {{Path|/boot}}. Run <code>awk '$2 ~ /boot/ && $3 ~ /fat|msdos/ { print $2 }' /proc/mounts</code> to confirm.
; fwa : The respective [https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-disk.in#L320-324 firmware architecture] for your system

==== Short-term work-around ====

A short-term work-around to get the system bootable again is to restore the backup configuration:

{{Cmd|cp /boot/grub/grub.cfg.back /boot/grub.cfg }}

This should allow you to boot the system again to fix it permanently. This will be reverted again when either grub or the kernel is updated again.

This will only work if <code>update-grub</code> has not been executed any more since the upgrade to grub 2.12.

== Others ==

=== Redis ===
Due to [https://github.com/redis/redis/pull/13157 the relicensing of Redis] to [https://redis.io/legal/rsalv2-agreement/ RSALv2]+[https://redis.io/legal/server-side-public-license-sspl/ SSPLv1], a non-free license model, the [https://spdx.org/licenses/BSD-3-Clause.html BSD-3-Clause] licensed fork [https://valkey.io/ Valkey] has replaced Redis in the main package repository.

A [https://pkgs.alpinelinux.org/packages?name=valkey-compat valkey-compat] package is provided with symlinks and group for easy Redis replacement.

The [https://pkgs.alpinelinux.org/packages?name=redis redis aport] has been moved to the community repository, with a shorter support cycle, and will not be upgraded past 7.2.x due to the license change.

Another replacement alternative, the [https://spdx.org/licenses/LGPL-3.0-only.html LGPL-3.0-only] licensed fork [https://redict.io/ Redict] is also available in the community repository.

=== yq ===
yq was renamed to yq-go. https://gitlab.alpinelinux.org/alpine/aports/-/issues/16052

=== aws-cli ===
Due to incompatibility issues with Python 3.12, aws-cli has been temporarily disabled until the issue is resolved by upstream. See the corresponding problem at upstream: https://github.com/aws/aws-cli/issues/8342

=== GNOME 46 ===

New upstream release of GNOME.

Depending on how you installed GNOME, you may have to manually add <code>gcr-ssh-agent</code> after upgrading to retain GNOME Keyring ssh integration.

Release Notes for Alpine 3.20.0

2024-05-08T08:44:41Z

Newbyte: /* Others */

Release Notes for Alpine 3.20.0

2024-04-16T12:59:46Z

Newbyte: Fix missing closing tag

Release Notes for Alpine 3.16.0

2022-05-04T13:30:29Z

Newbyte:

== Important changes ==

=== /tmp mounted as tmpfs ===

Previously <code>/tmp</code> was just part of the root filesystem and was cleaned on boot via the bootmisc openrc service script. In v3.16, on new installation, <code>/tmp</code> will be mounted as tmpfs.

== New features and noteworthy new packages ==

=== Fixed not showing boot output using consoles with drivers compiled as modules ===

Fixed OpenRC output not being shown on VirtIO consoles.

=== SDL 1.2 migrated to SDL 1.2 compat ===

The old sdl package (SDL 1.2) was moved from community to testing and as such won't be part of Alpine 3.16. Applications that use sdl instead use sdl12-compat, which is based on the much more well-maintained sdl2 (SDL 2.0). This results in various improvements such as support for Wayland, PipeWire, and more gamepads.

== Significant updates ==

=== KDE ===

Plasma has been upgraded from 5.23 to 5.24.

KDE applications (the release service) have been upgraded from 21.08 to 22.04 and KDE Frameworks have been upgraded from 5.88 to 5.93.

Plasma Mobile Gear have been upgraded from 21.12 to 22.04.

=== GNOME 42 ===

Most GNOME packages have been upgraded to version 42.

Release Notes for Alpine 3.16.0

2022-05-04T13:30:19Z

Newbyte: Add SDL 1.2 compat -> 2.0

== Important changes ==

=== /tmp mounted as tmpfs ===

Previously <code>/tmp</code> was just part of the root filesystem and was cleaned on boot via the bootmisc openrc service script. In v3.16, on new installation, <code>/tmp</code> will be mounted as tmpfs.

== New features and noteworthy new packages ==

=== Fixed not showing boot output using consoles with drivers compiled as modules ===

Fixed OpenRC output not being shown on VirtIO consoles.

== SDL 1.2 migrated to SDL 1.2 compat ==

The old sdl package (SDL 1.2) was moved from community to testing and as such won't be part of Alpine 3.16. Applications that use sdl instead use sdl12-compat, which is based on the much more well-maintained sdl2 (SDL 2.0). This results in various improvements such as support for Wayland, PipeWire, and more gamepads.

== Significant updates ==

=== KDE ===

Plasma has been upgraded from 5.23 to 5.24.

KDE applications (the release service) have been upgraded from 21.08 to 22.04 and KDE Frameworks have been upgraded from 5.88 to 5.93.

Plasma Mobile Gear have been upgraded from 21.12 to 22.04.

=== GNOME 42 ===

Most GNOME packages have been upgraded to version 42.

Release Notes for Alpine 3.16.0

2022-05-04T13:24:49Z

Newbyte:

Release Notes for Alpine 3.16.0

2022-05-04T13:24:34Z

Newbyte:

User:Newbyte

2021-12-04T11:53:58Z

Newbyte:

Hi! I'm Newbyte.

My notes for upgrading GNOME: [[User:Newbyte/Upgrading_GNOME]]

User:Newbyte/Upgrading GNOME

2021-12-04T11:51:54Z

Newbyte: Created page with "== List of packages to upgrade when upgrading GNOME == Note that this list probably is incomplete. * baobab * calls * eog * gcr * gdm * gjs * glib-networking * gnome-boxes *..."

== List of packages to upgrade when upgrading GNOME ==

Note that this list probably is incomplete.

* baobab
* calls
* eog
* gcr
* gdm
* gjs
* glib-networking
* gnome-boxes
* gnome-builder
* gnome-calendar
* gnome-characters
* gnome-chess
* gnome-contacts
* gnome-control-center
* gnome-desktop
* gnome-font-viewer
* gnome-initial-setup
* gnome-maps
* gnome-music
* gnome-online-accounts
* gnome-remote-desktop
* gnome-screenshot
* gnome-session
* gnome-settings-daemon
* gnome-shell
* gnome-shell-extensions
* gnome-system-monitor
* gnome-terminal
* gnome-user-docs
* gnome-weather
* gsettings-desktop-schemas
* gtksourceview4
* gtksourceview5
* gtkmm3
* gtk-vnc
* libadwaita
* libdazzle
* libhandy1
* mutter
* nautilus
* orca
* simple-scan
* tracker
* tracker-miners
* yelp-tools
* yelp-xsl

User:Newbyte

2021-12-04T11:38:44Z

Newbyte: Created page with "Hi! I'm Newbyte."

Hi! I'm Newbyte.

Release Notes for Alpine 3.15.0

2021-11-08T09:44:30Z

Newbyte: Add GNOME 41

== aports ==

=== 5.15 LTS kernels ===

linux-lts and linux-virt upgraded to 5.15

=== QtWebKit was removed due to lack of upstream support ===

qt5-qtwebkit, kdewebkit, wkhtmltopdf, and py3-pdfkit have been removed due to known vulnerabilities and lack of upstream support for qtwebkit. Other programs have been adjusted to use qt5-qtwebengine where appropriate. The most direct replacement for wkhtmltopdf is weasyprint, which is available in the Alpine Linux community repository. puppeteer and pandoc are also options, depending on your needs. See [https://gitlab.alpinelinux.org/alpine/aports/-/issues/12888 #12888] for more information.

=== radvd no longer enables ipv6 forwarding ===

The radvd init script no longer enables ipv6 forwarding. To enable ipv6 forwarding (necessary for most networks), add <code>net.ipv6.conf.all.forwarding=1</code> to {{path|/etc/sysctl.conf}} or to a file in {{path|/etc/sysctl.d}}.

=== New package signing keys ===

New signing keys have been generated for v3.15 ongoing. The key size has been increased from 2048 bits to 4096 bits. Make sure you have <code>alpine-keys-2.4-r0</code> or later before upgrading to 3.15 (or downgrading from edge).

=== Ruby 3.0.2 ===

Ruby has been upgraded to version 3.0.2.

=== LLVM12 added ===

LLVM12 is now available.

=== KDE ===

KDE Plasma has been upgraded to version 5.23, and KDE Applications have been upgraded to 21.08.
Plasma Mobile Gear has been upgraded to 21.10.

=== Node.js ===

Node.js (LTS) has been upgraded to version 16.13.0. nodejs-current has been upgraded to 17.0.1.

=== PHP ===

PHP 7.4 started to phase out (1 year of security support left).
Transition to 8.0 is not finished yet as some app still require old version.

=== Postgresql 14 ===

Postgresql has been upgraded to version 14.0.

=== Mercurial ===

mercurial has been upgraded to 5.9.3

=== MIPS64 discontinued ===

The build hardware we use for building the packages is broken and the architecture is EOL, so there is no new hardware available anymore. As a consequence, there will be no v3.15 release for mips64, and existing releases can no longer receive security updates, so continued use of this architecture is not recommended.

=== Dlang build tools (DMD, DUB, LDC) have been updated ===

Both compilers have been updated to frontend version v2.098.0 (LDC equivalent: v1.28.0).
Dub has been updated to v1.27.0.
LDC now always uses `--export-dynamic` so that code compiled without debug infos (`-g`) will still have the function name in its stack trace.

=== OpenJDK 17 added ===

The latest OpenJDK LTS version (17) has been added to this release and is available via the community repository.

=== GNOME 41 ===

Most GNOME packages have been upgraded to version 41.

GNOME

2021-10-06T11:26:42Z

Newbyte: Update gnome-apps install commands to reflect current situation.

= Prerequisites =

* [[Installation|Alpine Installation]]
* [[Setting_up_a_new_user#Creating_a_new_user|Create user accounts]]
* [[Alpine_setup_scripts#setup-xorg-base|Graphical base environment]]
* [[Enable_Community_Repository#Using_community_repositories|Enabled "community" repository]]

= Installing packages =

Install basic desktop system and gnome packages.
{{Cmd|# apk add gnome}}

If you want, you can install additional GNOME apps for a more complete GNOME experience with:
{{Cmd|# apk add gnome-apps-core}}

And further extra GNOME apps with
{{Cmd|# apk add gnome-apps-extra}}

= Graphical login =
To start the GDM display manager and login with your user, you need a user other than root for this to succeed. GDM will refuse to start if no user accounts (accounts with a UID >= 1000) are available.
{{Cmd|rc-service gdm start}}

Once you have verified correct operation, you can make GDM start at boot:
{{Cmd|rc-update add gdm}}

= Enabling terminal apps =
If you want to use the gnome-terminal/other terminal applications you will need to install bash. If you want a typical bash setup also enable bash completion:
{{cmd|# apk add bash}}
{{cmd|# apk add bash-completion}}

= Troubleshooting =
If you are unable to log in, check /var/log/gdm/greeter.log, there may be info there from X that indicates failed modules, etc.

If logging in from GDM kicks you back to the login screen, try {{cmd|# apk add bash}} (bug report: #10953 sorry cannot link yet)

If GNOME Terminal doesn't start, add the following to /etc/locale.conf: LANG=en_US.UTF-8 and reboot.

If the on-screen keyboard shows up in GDM after installing other UIs such as Phosh, you need to disable it by opening the Accessibility menu (top right) when you are in the GDM login screen. You can disable the on-screen keyboard there. Or set <code>org.gnome.desktop.a11y.applications screen-keyboard-enabled</code> to <code>false</code> for the <code>gdm</code> user with <code>dconf</code>

[[Category:Desktop]]

APKBUILD Reference

2021-07-17T12:08:47Z

Newbyte: Remove redundant comma

APKBUILDs are the scripts that are created in order to build Alpine packages using the [[abuild]] tool.

See [[aports]] for details on Alpine's official ports repository.

This page is intended to serve as a reference for creating APKBUILDs; if this is your first time creating a package for Alpine Linux, please see [[Creating an Alpine package]].

= Legend =
The following notes will assist you in understanding this document.

In description text:
* If a variable is not prefixed with a ''$'', it will be represented by italics (i.e., ''srcdir'' ).
* Functions will also be represented by italics, but will also end with a pair of parentheses (i.e., ''build()'' ).
* Shell commands will be represented <code>like this</code>.

= Variables =
{{Note|Variables that contain a path (e.g. ''$srcdir'' and ''$pkgdir'') should always be quoted using double quotes (i.e., ''"$srcdir"''). This is done to prevent things from breaking, should the user have the APKBUILD in a directory path that contains spaces.}}
{{Note|All arbitrary variable and function names should be prefixed with an underscore character ( _ ) to avoid name clashes with the internals of abuild (for example, ''_luaversions'').}}

== abuild-defined variables ==
The following variables are defined by abuild:

==== startdir ====
: The directory where the APKBUILD script is.
==== srcdir ====
: The directory where sources, from the ''source'' variable, are downloaded to and unpacked to.
==== pkgdir ====
: This directory should receive the files for the main package. For example, a normal [http://en.wikipedia.org/wiki/GNU_build_system autotools] package would have <code>make DESTDIR="$pkgdir" install</code> in the ''package()'' function.
==== subpkgdir ====
: This directory should receive the files for a subpackage. This variable should only be used from subpackage functions.
==== builddir ====
: This variable should point to the directory inside the ''srcdir'' where the main package source is unpacked. This is typically ''$srcdir/$pkgname-$pkgver''. It’s used by the default ''prepare()'' function as a working directory when applying patches.

== User-defined variables ==
The following variables should be defined by the user:
==== arch ====
: Package architecture(s) to build for. Can be one or several seperated by whitespace of: '''[[x86]], [[x86_64]], [[armv7]], [[armhf]], [[aarch64]], [[ppc64le]], [[s390x]], [[mips64]], all''', or '''noarch''', where '''all''' means all architectures, and '''noarch''' means it's architecture-independent (e.g., a pure-python package). Architectures can be negated using the ! character to exclude them from the list of supported architectures. E.g. '''arch="all !ppc64le"''' means that the package is allowed to be built on all architectures but the ppc64le architecture.
: {{Tip|To determine if your APKBUILD can use '''noarch''': First specify '''all''' and then build the package by executing <code>abuild -r</code>. Watch the output towards the end for warnings saying that '''noarch''' can be used. If the main package and all subpackages, if you have any subpackages, give a warning saying that '''noarch''' can be used, then you can use '''noarch'''.}}

==== depends ====
: Run-time dependency package(s) that are not shared-object dependencies. Shared objects dependencies are auto-detected and should not be specified here. To specify a conflicting package, add the package name prefixed with a '!'.

==== depends_dev ====
: Run-time dependency package(s) for the '''$pkgname-dev''' subpackage.

: {{Note|From ncopa on IRC: To find out if you need to add a package to depends_dev have a look at *requires* in usr/lib/pkgconfig/*.pc. With libtool it gets more complicated, but we should delete the .la files. Also check if there are any /usr/bin/*-configure #!/bin/bash #!/usr/bin/perl or Python. Sometimes scripts or similar are generated at build time (i.e autoconf automake) then you normally don't need add those to depends_dev. You can also just add all -dev makedepends to depends_dev but it will slow the build process a little bit (more build dependencies).}}

==== depends_doc ====
: Run-time dependency package(s) for the '''$pkgname-doc''' subpackage.

==== depends_openrc ====
: Run-time dependency package(s) for the '''$pkgname-openrc''' subpackage.

==== depends_libs ====
: Run-time dependency package(s) for the '''$pkgname-libs''' subpackage.

==== depends_static ====
: Run-time dependency package(s) for the '''$pkgname-static''' subpackage.

==== checkdepends ====
: Dependencies that are only required during the check phase, they are only installed if the check option is enabled

==== giturl ====
:Git repository from which <code>abuild checkout</code> checks out. You can checkout a specific branch in git by adding <code>-b $branch</code>.
==== install ====
: There are 6 different types of install scripts. Install scripts are named '''$pkgname.action''', where '''action''' can be: '''pre-install, post-install, pre-upgrade, post-upgrade, pre-deinstall''', or '''post-deinstall'''. For example, if ''pkgname'' is set to '''mypackage''' and ''install'' is set to '''$pkgname.post-install''', then a script named '''mypackage.post-install''' must exist along-side the APKBUILD.
<blockquote>{{Note|Always use <code>/bin/sh</code> for the command-line interpreter on the [http://en.wikipedia.org/wiki/Shebang_%28Unix%29 shebang line] of your install scripts.}}</blockquote>

The following are the different types of install scripts in detail:

===== $pkgname.pre-install =====
: This script is executed ''before installing'' the package. Typical use is when the package needs a group and a user to be created. For example:
<blockquote><pre>
#!/bin/sh

addgroup -S clamav 2>/dev/null
adduser -S -D -H -s /bin/false -G clamav -g clamav clamav 2>/dev/null

exit 0
</pre>
{{Note|If the script exits with a failure (e.g., if the user already exists), the package will not be installed and <code>apk</code> will exit with failure, hence the <code>exit 0</code> at the end.}}</blockquote>

===== $pkgname.post-install =====
: This script is executed ''after installing'' the package.

===== $pkgname.pre-upgrade =====
: This script is executed ''before upgrading/downgrading/reinstalling'' the package. Note that exiting with failure will not cause apk to exit with failure, but will mark the package as broken.

===== $pkgname.post-upgrade =====
: This script is executed ''after upgrading/downgrading/reinstalling'' the package.

===== $pkgname.pre-deinstall =====
: This script is executed ''before uninstalling'' the package.
: {{Note|If the script exits with failure, <code>apk</code> will not uninstall the package.}}

===== $pkgname.post-deinstall =====
: This script is executed ''after uninstalling'' the package.

==== install_if ====
:install_if can be used when a package needs to be installed when some packages are already installed or are in the dependency tree. It works in reverse to the ''recommends'' feature, that other package managers provide.

: Typically this is used in a subpackage that should provide files which make sense with another package. For example:
<blockquote><pre>
...
subpackages="$pkgname-bash-completion:bashcomp:noarch"
...
bashcomp() {
pkgdesc="Bash completions for $pkgname"
install_if="$pkgname=$pkgver-r$pkgrel bash-completion"

install -Dm644 "$builddir"/doc/bash_completion/aria2c \
"$subpkgdir"/usr/share/bash-completion/completions/_aria2c
}
</pre>
From the aria2c APKBUILD. Note that the custom bashcomp() function is only necessary, because the files are not in /usr/share/bash-completion.
</blockquote>

:In general, install_if should only be used with '''at least one versioned constraint'''. Otherwise, a package that was implicitly installed by install_if and then removed from the binary repositories, will not get purged with <code>apk upgrade</code>. [https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10720#note_121298]

==== license ====
: License(s) for the package, for example <code>GPL-3.0-or-later</code>, <code>BSD-2-Clause</code> or <code>MIT</code> [[Creating_an_Alpine_package#license|(details)]].

==== makedepends ====
: Build-time dependency package(s).
==== md5sums/sha256sums/sha512sums ====
: Checksums for the files/URLs listed in ''source''. The checksums are normally generated and updated by executing <code>abuild checksum</code> and should be the last item in the APKBUILD.

New packages should use only sha512sums.

==== options ====
: Build-time options for the package.

: {| class="wikitable"
! Option
! Description
|-
| <code>!archcheck</code>
| Do not try to verify that the architecture of the binary files is the same architecture as abuild should build for. One example where it makes sense to set this are packages with firmware files, that get executed on another CPU (such as WiFi firmware).
|-
| <code>!check</code>
| Do not try to run the <code>check()</code> function. Please always add a short comment after the <code>!check</code> about why it's disabled. [https://github.com/alpinelinux/aports/pull/2322#discussion_r142545300] Creating a very simple check function, that calls <code>program --version</code> is worse than disabling tests completely because it gives the false impression that the package is thoroughly tested with the testsuite from upstream. [https://github.com/alpinelinux/aports/pull/7326#discussion_r278797457]
|-
| <code>checkroot</code>
| Specifies that the package's test suite will be run in ''fakeroot''. This is necessary for some test suites which fail when run as non-root.
|-
| <code>net</code>
| Allows network access when run in ''rootbld''.
|-
| <code>!strip</code>
| Avoid stripping symbols from binaries.
|-
| <code>suid</code>
| Allow [https://en.wikipedia.org/wiki/Setuid setuid] binaries.
|-
| <code>!tracedeps</code>
| Do not automatically find dependencies (e.g. by using <code>ldd</code> to find dynamic libraries, which the resulting binary links against).
|-
| <code>chmod-clean</code>
| Make all files writable in the src/ directory. Useful for packages that make files read-only in the process of building packages (go modules).
|-
| <code>toolchain</code>
| Don't warn when g++ is in makedepends
|-
| <code>!dbg</code>
| Don't create debugging subpackage
|-
| <code>ldpath-recursive</code>
| Scan directories recursively when creating .so providers
|-
| <code>!spdx</code>
| Do not check if the license= field has a SPDX compliant license
|-
| <code>textrels</code>
| Don't error out when text relocations are found
|-
| <code>charset.alias</code>
| Don't error out if /usr/lib/charset.alias is found
|-
| <code>libtool</code>
| Don't delete libtool .la files
|-
| <code>!fhs</code>
| Don't enforce checks on path that follow the FHS
|}

==== pkgdesc ====
: A brief, one-line description of what the package does.

: Here's an example from the OpenSSH client package:
: <pre>pkgdesc="Port of OpenBSD's free SSH release - client"</pre>
==== pkggroups ====
: System group(s) to be created during build-time. System group(s) should also be created in the '''[[APKBUILD Reference#.24pkgname.pre-install|$pkgname.pre-install]]''' script, so that the system group(s) are also created prior to package installation for run-time use.
==== pkgname ====
: The name of the package. All letters should be lowercase.
: {{Note|When creating an APKBUILD of a module or library for another package, we use some common package prefixes, such as: ''lua-'', ''perl-'', ''php-'', and ''py-''. Search aports for other common prefixes.}}

==== pkgrel ====
: Alpine package release number. Starts at 0 (zero). Always increment ''pkgrel'' when making updates to an aport; reset ''pkgrel'' to 0 (zero) when incrementing ''pkgver''.
==== pkgusers ====
: System user(s) to be created during build-time. System user(s) should also be created in the '''[[APKBUILD Reference#.24pkgname.pre-install|$pkgname.pre-install]]''' script, so that the system user(s) are also created prior to package installation for run-time use.
==== pkgver ====
: The version of the software being packaged. Format for valid versions: <code>{digit}{.digit}...{letter}{_suf{#}}...{-r#}</code> [https://git.alpinelinux.org/cgit/apk-tools/tree/src/version.c#n17]
: A Suffix <code>suf</code> in the above format can be one of the following to indicate that the release is ''less recent'' than the version without the suffix: <code>alpha</code>, <code>beta</code>, <code>pre</code>, <code>rc</code> [https://git.alpinelinux.org/cgit/apk-tools/tree/src/version.c#n75]
: These are for indicating ''more recent'' releases: <code>cvs</code>, <code>svn</code>, <code>git</code>, <code>hg</code>, <code>p</code> [https://git.alpinelinux.org/cgit/apk-tools/tree/src/version.c#n76]
: All other suffices are invalid. To package a specific git commit, the date of the commit gets appended to the latest release, e.g. <code>1.0.0_git20180204</code>.

==== provides ====
: List of package names (and optionally version info) this package provides.

: If package with a version is provided (provides='foo=1.2') apk will consider it as an alternate name and it will automatically consider the package for installation by the alternate name, and conflict with other packages having the same name, or provides.

: If version is not provided (provides='foo'), apk will consider it as virtual package name. Several package with same non-versioned provides can be installed simultaneously. However, none of them will be installed by default when requested by the virtual name - instead, error message is given and user is asked to choose which package providing the virtual name should be installed.
==== provider_priority ====
: A numeric value which is used by apk-tools to break ties when choosing a virtual package to satisfy a dependency. Higher values have higher priority. The primary use case is to specify the primary package that satisfies a virtual (provider).
==== replaces ====
: Allow this package to be installed at the same time as the listed packages, even if they have conflicting files. The files from this package will override ("take over") the conflicting files.

: This can be used to override config files with "policy packages" [https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/89d003f8c2e5a92655ee778f7bfa5c0e85ddbed4].

: Another use case is renaming packages (or moving files from one package to another): "replaces" will avoid the file conflict error that apk reports if it happens to install the new package before uninstalling the old package [https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10724#note_132872].

: A common misconception is that "replaces" is used to replace packages (like in [https://wiki.archlinux.org/index.php/PKGBUILD#replaces PKGBUILD]). This is not the case, it is only for solving file conflicts. To let apk consider installing one package instead of another one, refer to [[#provides|provides]] (with the version).

==== replaces_priority ====
: The priority of the replaces. If multiple packages replace files of each other, then the package with the highest ''replaces_priority'' will win.

==== source ====
: The source variable is not only used to list the remote source files to fetch, it is also used to list the local files that abuild will need in order to build the apk. Examples of such local files include: init.d files, conf.d files, install files (see [[APKBUILD Reference#install|install variable]]), patches, and all other necessary files.

: Here are few things to note:

:* When you are finished adding local and/or remote files to ''source'', you can execute the following command to add their checksums to the APKBUILD file:
:: {{Cmd|abuild checksum}}
:: {{Note|When later updating the content of ''source'', or updating a file that is listed in ''source'', you must also update their checksums again with the same command.}}

:* When the remote file is hosted at SourceForge, it's best to specify the special mirrors link used by SourceForge:
:: <pre>http://downloads.sourceforge.net/software/software-$pkgver.tar.gz</pre>
:: (or similar depending on the package).

:* You can set target filename (eg 'save as...') by prefixing the URI with ''filename::''. This is useful when the remote filename is not specified in the URI (ie, does not end in '/software-1.0.tar.gz'), such as:
:: <pre>http://oss.example.org/?get=software&ver=1.0</pre>
:: or when the filename is braindead, like githubs' download tags:
:: <pre>https://github.com/software/software/archive/v$pkgver.tar.gz</pre>
:: The above two examples needs a target filename prefix:
:: <pre>$pkgname-$pkgver.tar.gz::http://oss.example.org/?get=software&ver=$pkgver</pre>
:: and:
:: <pre>$pkgname-$pkgver.tar.gz::https://github.com/software/software/archive/v$pkgver.tar.gz</pre>

:* abuild currently supports the following protocols for remote file retrieval:
:** http
:** https
:** ftp

:* abuild currently supports the following archive types/archive file extensions:
:** .tar (only in Alpine >= 2.5)
:** .tar.gz / .tgz
:** .tar.bz2
:** .tar.lz (only in Alpine >=3.7)
:** .tar.lzma
:** .tar.xz
:** .zip

:* <code>source</code> should only include variables that change often like <code>pkgver</code> or a commit ID. CI will warn you if you include <code>pkgname</code> in source. Other variables like for example <code>_pkgname</code> or <code>_pyname</code> do not belong in <code>source</code> either.

==== subpackages ====
: Subpackages built from this APKBUILD. abuild will parse this variable and try to find a subpackage split function. The split function must ''move'' files that do not belong in the main package, from ''$pkgdir'' to ''$subpkgdir''. Files and directories can also be ''copied'' from ''$startdir'' and ''$srcdir'' to ''$subpkgdir''.

: The split function can be specified in 1 of 3 different methods:
:# subpkgname:'''splitfunc'''
:# $pkgname-'''splitfunc'''
:# '''splitfunc'''

: {{Note|Split function names '''cannot''' use hyphens; use the first method above if the subpackage name contains a hyphen (-) character, like this: ''subpkg-name:subpkg_name'', where <code>subpkg-name</code> is the name of the '''subpackage''' and <code>subpkg_name</code> is the name of the '''subpackage's split function'''.}}

: {{Tip|For more information, see the [[APKBUILD_examples:Subpackages|Subpackages example]].}}

==== triggers ====
: Apk-tools can "monitor" directories and execute a trigger if any package installed/uninstalled any file in the monitored dir. The triggers are always executed after the apk action (install, uninstall, upgrade).

: The triggers are specified in the format: ''scriptname''=''pathlist'' where ''scriptname'' is the (sub)package name + .trigger suffix and pathlist is : separated list of the dirs to monitor.

: The '''triggers''' variable must include the triggers for subpackages too if they have any.

: It is possible to use wildcards (*) in the dir list.

==== url ====
: The homepage for the package. This is to help users find upstream documentation and other information regarding the package.

==== langdir ====
: Path to where the language files are located for the '''-lang''' subpackage, defaults to '''/usr/share/locale'''

==== pcprefix ====
: Prefix all provides derived from parsing pkg-config Requires: with the value in this variable, example: ''''pcprefix="foo:"''' will produce '''pc:foo:bar'''

==== sonameprefix ====
: Prefix all provides derived from parsing shared objects with the value in this variable, example: '''sonameprefix="foo"''' will produce '''so:foo:bar.so.X'''

= Functions =
{{Note|All functions that are not ''prepare()'', ''build()'', ''check()'' and ''package()'' should consider the current working directory as undefined, and should therefore use the [[APKBUILD Reference#abuild-defined_variables|abuild-defined directory variables]] to their advantage.}}

sanitycheck() -> clean()-> fetch() -> verify() -> unpack() -> prepare() -> mkusers() -> build() -> check() -> package() -> subpackages() -> language packs -> apk -> cleanup()

== abuild-defined functions ==
The following functions are provided by abuild and can be overridden, but it is strongly discouraged on code review for some functions:

==== fetch() ====
: Downloads remote sources listed in ''source'' to ''SRCDEST'' (''SRCDEST'' is configured in ''/etc/abuild.conf'') and creates symlinks in ''$srcdir''.
==== unpack() ====
: unpack() will call default_unpack().

: [https://github.com/alpinelinux/abuild/blob/v3.1.0/abuild.in#L403 default_unpack()] unpacks .tar, .tgz, .tar.gz, .tar.lz (only available in Alpine >=3.7), .tar.bz2, .tar.lzma, .tar.xz, and .zip archives from a symlink in ''$srcdir'' associated with ''$SRCDEST'' (or distfiles folder) resulting in an unpacked folder in ''$srcdir''.

==== dev() ====
: Subpackage function for the '''$pkgname-dev''' package is used to collect developer files and folders for use in other packages in the compilation process nothing more. Without specifying a custom ''dev()'' function, abuild will call its internal ''dev()'' function, which in turn calls default_dev().

: ''[https://github.com/alpinelinux/abuild/blob/v3.1.0/abuild.in#L1605 default_dev()]'' will move any ''include'' folder and folders containing ''*.[acho]'' (static archive, c source, c header file, object file), ''*.prl'' file extension patterns in ''"$pkgdir"/{lib,usr}'' to ''"$subpkgdir"/{lib,usr}'' recursively; and ''*.so'' files from ''"$pkgdir"/{lib,usr/lib}'' to ''"$subpkgdir"/{lib,usr/lib}''. It will also scan and move ''usr/{include,lib/{pkgconfig,cmake,qt*/mkspecs},share/{aclocal,gettext,vala/vapi,gir-[0-9]*,qt*/mkspecs},bin/*-config}}'' developer only folders in ''$pkgdir'' and transfer them to ''$subpkgdir''.

: In general, default_dev() will support packages that share pkg-config, C programming language API, shared and static libraries, Autotools, gettext, Vala programming language bindings, Python GObject introspection, a provided custom pkg-config like command (*-config), Qt, and CMake. If you have packages that have C++, other languages, other build system, etc; you need to manually move those developer files only if they are to be used in other packages.

: '''Important''': For default_dev() to be called as in no dev(), you need to explicitly add subpackages="$pkgname-dev".

==== doc() ====
: Subpackage function for the '''$pkgname-doc''' package whose job is only to collect documentation folders from $pkgdir nothing more. Without specifying a custom ''doc()'' function, abuild will call its internal ''doc()'' function, which in turn calls default_doc().

: ''[https://github.com/alpinelinux/abuild/blob/v3.1.0/abuild.in#L1519 default_doc()]'' will move ''"$pkgdir"/usr/share/{doc,man,info,html,sgml,licenses,gtk-doc,ri,help}'' to ''$subpkgdir''.

: Overriding this function is strongly discouraged. Packaging docs should be done in the package() function while letting abuild automatically collect the doc folders.

: '''Important''': For default_doc() to be called as in no doc(), you need to explicitly add subpackages="$pkgname-doc".

==== openrc() ====
: Subpackage function for the '''$pkgname-opernc''' package whose job is to collect OpenRC service files that are in /etc/init.d and /etc/conf.d.

: ''[https://github.com/alpinelinux/abuild/blob/v3.1.0/abuild.in#L1661 default_openrc()]'' will move ''"$pkgdir"/etc/{conf,init}.d'' to ''$subpkgdir''.

: Overriding this function is strongly discouraged. Packaging OpenRC service definitions should be in the package() function while letting abuild automatically collect the openrc folders.

: '''Important''': for default_openrc() to be called as in no openrc(), you need to explicitly add subpackages="$pkgname-openrc".

==== static() ====
: Subpackage function for the '''$pkgname-static''' package whose job is to collect static libraries that are stored in /lib and /usr/lib.

: ''[https://github.com/alpinelinux/abuild/blob/v3.4.0_rc4/abuild.in#L1748 default_static()]'' will move all static libraries (files ending with .a) from ''"$pkgdir"/lib'' and ''"$pkgdir"/usr/lib'' to their equivalents in ''$subpkgdir''.

: Overriding this function is strongly discouraged. Packaging static libraries should be done in the package() function while letting abuild automatically collect the static libraries.

: '''Important''': for default_static() to be called as in no static(), you need to explicitly add subpackages="$pkgname-static".

==== snapshot() ====
: '''Optional'''. For live APKBUILDs or those with a _cvs, _svn, _git, _hg in their version number, you should create a snapshot function only if there is no download link to an archive file (.zip, .tar.gz, ...) to the commit/hash/tag. The purpose of the snapshot function is to create an archive of the source code so that the package source code is deterministic, and it doesn't waste time to fetch the source code but bypasses the download step after snapshotting. Those that download the source code from a git repository will follow head or the latest change to the source code. It is better to archive the source code as a zip / tar.gz / tar.bz2 up to the commit or the tag which you are trying to build a package. If it is not deterministic or not every part of the code frozen in time for every dependency and the main project, then the patches will fail or the package may fail to compile when you revisit the package months or years to backport a patch.

: The default [https://github.com/alpinelinux/abuild/blob/v3.1.0/abuild.in#L2310 snapshot()] function has variables associated with it:
:* $disturl - the base-url of the place to autoupload the snapshot
:* $svnurl - Subversion repository
:* $giturl - Git repository

: The default snapshot() can only support one repository. It is better to override it if there are multiple repositories involved in your package. CVS, Mercurial (hg), and alternative version control systems must override the default snapshot().

: See [[APKBUILD_examples:Git_checkout]] to how to use it with git. It takes 2-3 general steps. Clone the repository; check it out at a specific revision/commit or tag; then you use an archiver to dump it in the ''$SRCDEST'' variable which points to the distfiles folder and the base path to the full path to the archive that you want to create. You do this for every internal dependency that the package pulls.

: After you have created your snapshot function, you use <code>abuild snapshot</code> to run it.

: The archives produced by the snapshot will be saved in ''/var/cache/distfiles'' or whatever you set for ''$SRCDEST''. You may need to create symlinks to the archive if the archive is not saved to the Alpine server.

: After you snapshot it, you need to produce the checksums with <code>abuild checksum</code> to use it in the APKBUILD creation process.

: This feature is available since Alpine >=2.6.

==== default_prepare() ====

: Before build preparation it handles set of patches inside <code>$srcdir</code> and prints failed ones.

== User-defined functions ==
The following functions should be defined by the user:

==== prepare() ====
: {{note|Please adjust old APKBUILDs, which still have a ''prepare()'' function that does the same as the ''default_prepare()'' when you edit them anyway.}}
: '''''Optional''.''' Used for build preparation: patches, etc, should be applied here. When you don't specify a custom ''prepare()'', the built-in ''default_prepare()'' from abuild will be used. It applies patches already (always prepare them in the <code>-p1</code> format), so '''usually it makes sense to not create a custom ''prepare()'' function at all!''' If you do create one, call ''default_prepare()'' inside it:

: Before default_prepare gets called, you can define ''patch_args'' to supply the argument to the patch command in global scope then throw away prepare() so it is unnecessary to use the old template code floating around to patch. patch_args and autopatching is only available in Alpine >=3.4. See [[Creating_an_Alpine_package#Patches]] to fix the patch that uses a different patch level (-pX).

<pre>
prepare() {
default_prepare
# your custom code here
}
</pre>

==== build() ====
: '''Required.''' This is the compilation stage. This function will be called as the current user (unless the ''package()'' function is missing - for compatibility reasons). If no compilation is needed, this function can contain a single line: <code>return 0</code>

: To enable or disable CFLAGS, CXXFLAGS, CMake with option, or configure option per arch, use the CARCH variable:
<pre>
local cmakeoptions=
case "$CARCH" in
aarch64*|arm*|ppc64le|x86|s390x) cmakeoptions="$cmakeoptions -DWITH_OPENMP=OFF" ;;
x86_64) cmakeoptions="$cmakeoptions -DWITH_OPENMP=ON" ;;
*) msg "Unable to determine architecture from (CARCH=$CARCH)" ; return 1 ;;
esac
</pre>
: The block can be used in other parts of the APKBUILD even in global.

==== check() ====
: '''Required if functionality exists.''' This function is called right after the build stage. It should check that the packaged thing is actually working, typically by running (integration) tests, if provided by upstream. If there’s no (easy) way how to test the package, you can declare that it does not want to use ''check()'' by adding "!check" into the ''options'' variable (<code>options="!check"</code>).

: default_check() does nothing. You need to manually explicitly call the unit tests or test suite yourself. When you run the test, the program should return with an exit code of 0, indicating the tests were a success. Unit tests or test suites will do feature tests, per function correctness check, fuzz testing, benchmarks.

: A package may also require additional testing frameworks packages that are external dependencies. You should add those to the ''checkdepends='' in Alpine >=3.6 or ''makedepends='' for older for backporters. If the testing framework is not available, you need to create a package for it. If it requires a specific version of a testing framework, consider making it an internal dependency or a new package with a package name containing the major and minor version number like the python packages.

: Generally speaking, you should define the check functions for libraries, large programs like web browsers, or compilers and interpreters, cryptographic/security/anonymity stuff, mission critical stuff, PCI compliance/money/accounting software, server software with a lot of stakeholders or consumers. Soon for the new policy change will have virtually '''all packages with testing capabilities be required to have a working and defined check() function'''.

: There are times when the unit tests do not work, just because the test itself is broken, new unimplemented feature, external factors not taken into consideration, unbundling path differences, breakage caused by ccache, missing test dependency or version mismatch dependency as in python2 vs python3, test scripts only work for particular language implementation like only supporting python2 but not python3 having used the 2to3 conversion script. If a unit test is known not to work, you may need to patch it to omit that test or fix it; but, certain tests should not be disabled if it is important. You may need to alter the references to uncompiled internal dependencies to work with the external dependencies instead. For ccache, you can either disable it or remove it from the PATH environmental variable before running tests.

{{Note|Tests for graphical applications and toolkits might work on a X11 user setup but will fail on the server unless run with xvfb-run.}}

: If you don't add the ''check()'' and the ''options='', this is what you will see:

>>> WARNING: py-webtest*: APKBUILD does not run any tests!
Alpine policy will soon require that packages have any relevant testsuites run during the build process.
To fix, either define a check() function, or declare !check in $options to indicate the package does not have a testsuite.

: If you do not do a check or disable it, you must state there is no testsuite in comment form (#) next to options="!check" for the code reviewers.

: To run test suite with autotools do:

make check

: To run the test suite with python setuptools:

python2 setup.py test
python3 setup.py test

: For python it should be '''test''' not check. Check for python setuptools will check the packaging metadata fields[https://docs.python.org/3/distutils/examples.html#checking-a-package] only but not run the unit tests. There should be verbose output also. The dependencies for the tests are found in test_require in the setup.py.

: If it says <code>Ran 0 tests in 0.000s</code> that is not acceptable. check() will say it was good but it is not actually correct. It needs to run the test suite with an alternative method like <code>tox -e py27,py36</code> if you see a tox.ini file.

: You want to do it for each implementation to ensure that the API calls are correct per implementation but ncopa said it was just fine with python3.

: If there is a circular dependency for the checkdepends=, you need to disable the check and put the reason next to <code>options="!check"</code> that there is a circular dependency. You should disable it for the package that package that is least important or least security risk. The other solution is to make the conflicting dependency an internal dependency but making sure that it doesn't pull it at check time. This way they can both preform tests properly.

==== package() ====
: '''Required.''' This is the packaging stage. Here, the built application and support files should be installed into '''$pkgdir'''. If this is a metapackage, this function can contain a single line: <code>mkdir -p "$pkgdir"</code>

{{Note|Building in fakeroot will reduce performance for parallel builds dramatically. It is for this reason that we split the build and package process into two separate functions.}}

= Examples =
The [[APKBUILD examples]] page will assist you in understanding how to create an APKBUILD.

= Version =

This document assumes abuild for Alpine Edge. For older releases of abuild, some of these features may not be available if you are using an older release. A link to the implementation is linked for researchers and backporters.

For more information see [[APKBUILD_versions]].

[[Category:Development]]

Python package policies

2021-06-17T15:46:03Z

Newbyte: Add note about projects not shipping a setup.py

Python packages in Alpine Linux should follow a general set of standards for their APKBUILDs.

{{Draft|Pending consensus on this approach, some discussion is taking place on the [[Talk:Python_package_policies|talk page]]}}

== Guidelines ==

* Prefix Python 3 libraries with py3-. Do not prefix programs (distinct from libraries) at all.

== General Template ==

Be sure to make the following changes:

* Update maintainer to yourself
* Set the pkgname to the Alpine package name (prefixed with "py3-")
* Set _pyname (see [[Talk:Python_package_policies|talk page]]) to the name of the package on PyPI
* Update the version number, pkgdesc, url, and license
* Build it and address any issues that come up
* Read the build output and be vigilant for issues listed in the following sections - the build may complete successfully even though these issues are present

=== Package template ===

Note that if you are removing python2 support from a package which previously had it, you should add <pre>replaces="py2-example"</pre> as well. If the old package was a split package, also add <pre>replaces="py-example"
provides="py-example=$pkgver-r$pkgrel"</pre>.

<pre># Maintainer: Joe Bloe <joe@example.org>
pkgname=py3-alpine-name
_pyname=pypi-name
pkgver=1.2.3
pkgrel=0
pkgdesc="Example Python package"
url="https://example.org"
arch="noarch"
license="MIT"
depends="python3"
makedepends="py3-setuptools"
_pypiprefix="${_pyname%${_pyname#?}}"
source="https://files.pythonhosted.org/packages/source/$_pypiprefix/$_pyname/$_pyname-$pkgver.tar.gz"
builddir="$srcdir/$_pyname-$pkgver"

build() {
python3 setup.py build
}

check() {
python3 setup.py test
}

package() {
python3 setup.py install --prefix=/usr --root="$pkgdir"
}</pre>

== Common issues ==

=== No source package available (only the wheel is on PyPI) ===

Seek out the upstream source (e.g. GitHub) and swap out the URL.

=== No tests in PyPI package "(0 tests run)" ===

Seek out the upstream source (e.g. GitHub) and swap out the URL.

=== setup.py test downloads a lot of dependencies ===

Watch out for this and be sure to add any of these packages to checkdepends so that setuptools isn't downloading and testing against packages/versions which aren't in aports.

=== You need to use the 'tox' utility to run tests ===

tox (knows as py3-tox on Alpine Linux) downloads all dependencies into a virtual environment by default, which bypasses the system tooling, making
testing somewhat less useful.

Remember to use *--sitepackages* on your invocation of tox in the check() phase so it uses the system packages instead of downloading ones into
a virtual environment.

=== setup.py does not exist ===

In case a package uses a pyproject.toml instead of setup.py, you can use [https://github.com/mgorny/pyproject2setuppy pyproject2setuppy]. You can use gvm-tools as reference for how to use it: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/gvm-tools.

== Alpine+Python projects ==

=== aports normalization project ===

Many Python packages in aports (if not most) do not follow these guidelines.

TODO: obtain consensus and organize this work.

=== Python 2 deprecation ===

{{Draft|Pending consensus on this approach}}

The general approach to Python 2 deprecation and removal requires three broad steps:

# Do not add new python 2 packages to aports, effective immediately.
# In the course of the aports normalization project, drop Python 2 support if it's easy or triage it and make a note for later if not.
# Making judgement calls for difficult packages on a case-by-case basis, based on the upstream's progress/amicability towards a Python 3 port. Upstreams which are unwilling to port to Python 3 should be removed from aports.

TODO: Prepare some discussion place, git repos, scripts, etc, to organize this work.

[[category: python]]

Requirements

2021-01-11T21:27:25Z

Newbyte: Architectures -> Architecture

This page will tell you what requirements you will need to use the Alpine Linux operating system:
__TOC__

== Hardware requirements ==

For installation and usage consider that Alpine can run on several kinds of devices, from the popular PC machine to video game consoles like the Game Boy Advance and the 3DS, and as such you must check the following of your machine:

** Architecture
** Memory
** Storage
** Peripherals

=== Architectures ===

'''Architecture means kind of computer. The most popular architecture is the misnamed "Intel IBM PC"''' or "i386" which is actually in fact the x86 or x64. There are other supported computer architectures that are not "x86", like mainframes, servers, and embedded devices (such as routers like Sonicwall and Cisco ones). Here are the architectures supported by Alpine:

{| class="wikitable"
|-
! Supported Arch !! Supported since !! Meaning of installation and target architecture
|-
| x86_64 || all || The popular AMD64 compatible 64-bit x86 based machines, i386 is not recommended for newer/latest hardware.
|-
| x86 || all || The all popular 32 bit intel (i386 pc 32bit) and x86_64 (i686 pc 64bit and amd64)compatible (both)
|-
| ppc64le || v3.6 || For the PowerPC devices with pure little-endian mode, mostly for POWER8 and POWER9
|-
| armhf || v3.0 || The newer ARM hard-float for newer, more powerful 32-bit devices alongside 64-bit. Including video games!
|-
| armv7 || v3.9 || The 32-bit ARM only execution state of the ARMv7 devices machines. Including video game consoles!
|-
| aarch64 || v3.5 || The 64-bit ARM only execution state of the ARMv8 device machines. Like Rasberri's
|-
| ppc64le || v3.6 || for 64-bit big-endian PowerPC and Power ISA processors like some MAC computers.
|-
| s390x || v3.6 || For the Super powered IBM mainframes, especially IBM Z and IBM LinuxONE servers.
|}

=== Memory ===

'''Means minimum amount of RAM memory. Need of RAM it depends of the meaning of the installation''', any hardware are supported and there is minimum sizes for:

{| class="wikitable sortable"
|-
! Target Arch !! Minimum RAM to start !! Minimum RAM to install !! Minimum RAM for GUI desktop !! Enough for GUI work
|-
| x86_64 || 512 Megs || 512 Megs || 2 Gigs || 8 Gigs
|-
| x86_32 || 128 Megs || 256 Megs || 1 Gigs || 3 Gigs
|-
| ppc64le || 128 Megs || 256 Megs || 2 Gigs || 8 Gigs
|-
| armhf || 256 Megs || 512 Megs || 1 Gigs || 6 Gigs
|-
| armv7 || 256 Megs || 512 Megs || 1 Gigs || 6 Gigs
|-
| aarch64 || 256 Megs || 512 Megs || 2 Gigs || 8 Gigs
|-
| ppc64le || 256 Megs || 512 Megs || 1 Gigs || 6 Gigs
|-
| s390x || 128 Megs || 256 Megs || 2 Gigs || N/A
|}

=== Storage ===

'''Means any external or internal storage device that can be added after or before install to use''' by the Alpine Linux system. Currently depends of the current linux kernel supported.

'''All the PATA and SATA hard disk drives are supported, also any USB or SD''' card that can be detected by USB BUS by the linux kernel subsystem during install.

=== Peripherals ===

'''Means any external or internal device that can be added after or before install to detectd''' by the Alpine Linux system. Currently depends of the current linux kernel supported.

ISA devices are not supported since 3.8 because kernel drops support.

Almost any GPU are supported, but for advanced features, 3D acceleration are manager by MESA project:

* Intel: mostly any Intel by one exception, intel i810/i815 will lack of features cos only has 4Mb memory, Mesa and Linux drop theit support.
* ATI/AMD, only radeon series with exception of recent two last years respect Alpine release, Rage r128/match64 series has limited support.
* Nvidia: limited; only few are complete supported! not all features are allowed!
* Matrox: not all features are supported, just cos are shipped on most servers.
* Sis: limited features are supported, since code are not updated on Xorg and Linux kernel
* Via: limited features are supported, since openchrome code are not updated on Xorg and Linux kernel

== Software requirements ==

** Media
** Booting
** Storage
** Firmware

=== Media ===

'''Means the files need for dump the install media, and later boot from the target install''' machine, of course downloaded from http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/ or main Download page.

{| class="wikitable"
|-
! Available for !! ISO (for USB, CD/DVD) !! IMG (for Netboot) !! TAR (for ROOTFS, in tar.gz) !! Download links
|-
| x86_64 || YES || YES || N/A || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/x86_64/
|-
| x86 || YES || YES || N/A || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/x86/
|-
| ppc64le || NO || YES || YES || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/ppc64le/
|-
| armhf || NO || YES || YES || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/armhf/
|-
| armv7 || NO || YES || YES || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/armv7/
|-
| aarch64 || YES || YES || YES || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/aarch64/
|-
| mips64 || YES || YES || N/A || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/mips64/
|-
| s390x || YES || YES || N/A || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/s390x/
|}

==== Checksum ====

'''Means Commands to verify the checksum and GPG signature of a downloaded image file on different systems, is complete optional!'''. This kind of check are made to verify if the download media ISO (for USB, CD/DVD), IMG (for Netboot) or TAR (for ROOTFS, in tar.gz) file are correct and will work. Just performs that command in your system before use that downloaded file:

{| class="wikitable"
! OS where media was downloaded !! <code>sha265</code> calculation (to be compared manually) !! <code>GPG</code> signature verification
|-
| Linux || <code>sha256sum -c alpine-*.iso.sha256</code> || <code>curl https://alpinelinux.org/keys/ncopa.asc | gpg --import ; <nowiki>gpg --verify alpine-*.iso.asc alpine-*.iso</nowiki></code>
|-
| MACOS || <code>shasum -a 256 alpine-*.iso</code> || - ? -
|-
| BSD || <code>/usr/local/bin/shasum -a 256 alpine-*.iso</code> || - ? -
|}

=== Booting ===

'''Means support for kind of BIOS setup of machine, and where can be media downloaded will be boot''', please for more info check [[Alpine_and_UEFI|Alpine and UEFI]] wiki page.

{| class="wikitable"
|-
! Supported Arch !! Supported BIOS !! Supported Types !! Media Boot Recommended
|-
| x86_64 || Coreboot, Vendor/OEM || BIOS, UEFI || '''USB''', CD/DVD (ISO)
|-
| x86 || Coreboot, Vendor/OEM || BIOS, UEFI || '''USB''', CD/DVD (ISO)
|-
| ppc64le || Coreboot, Vendor/OEM || BIOS, UEFI || '''USB''', CD/DVD (ISO)
|-
| armhf || Uboot, Vendor/OEM || BIOS, UEFI || '''NET''', MINIROOTFS (TAR.GZ)
|-
| armv7 || Uboot, Vendor/OEM || BIOS, UEFI || '''NET''', MINIROOTFS (TAR.GZ)
|-
| aarch64 || ?Coreboot?, Vendor/OEM || BIOS, ?UEFI? || '''USB''', CD/DVD (ISO)
|-
| mips64 || Vendor/OEM || ? || MINIROOTFS (TAR.GZ)
|-
| s390x || Vendor/OEM || BIOS, ?UEFI?|| '''USB''', CD/DVD
|}

If the computer does not automatically boot from the desired device, one needs to bring up the boot menu selection for choosing the media to boot from. Depending on the computer the menu may be accessed by quickly (repeatedly) pressing a key when booting starts, or sometimes it is needed to press the button before starting the computer and keep holding it when it boots. Typical keys are: `F9`-`F12`, sometimes `F7` or `F8`. If these don't bring up the boot menu, it may be necessary to enter the BIOS configuration and adjust the boot settings, for which typical keys are: `Del.` `F1` `F2` `F6` or `Esc.`

=== Space ===

'''This means amount of available space in disk partitions to perform a kind of install''' and of course will depends of type and meaning of your desired install, this are the recommended sizes but depends of the BIOS/UEFI supported you must perform and read the [[Alpine_and_UEFI#Alpine_disk_layout_for_UEFI|Alpine disk layout for UEFI/BIOS at Alpine and UEFI]] wiki page.

{| class="wikitable"
|-
! Minimum sizes !! Partition for BOOT (<code>/boot</code>) !! Partition for ROOT (<code>/</code>) !! Partition for HOME (<code>/home</code>) !! Partition for SWAP (<code>N/A</code>)
|-
| base only || 100 Megs || 500 Megs || 1 Gigs || Optional
|-
| default server || 200 Megs || 2 Gigs || 2 Gigs || 4 Gigs
|-
| default desktop || 250 Megs || 12 Gigs || 80 Gigs || 8 Gigs
|-
| mail server || 200 Megs || 20 Gigs || 20+ Gigs || 8 Gigs
|-
| web server || 200 Megs || 10 Gigs || 20+ Gigs || 8 Gigs
|}

= See Also =

# [[Installation]]
# [[Alpine_newbie#Install|Alpine_newbie Install section]]

[[Category:Installation]]

__FORCETOC__

Requirements

2021-01-11T21:26:39Z

Newbyte: Grammar edits.

This page will tell you what requirements you will need to use the Alpine Linux operating system:
__TOC__

== Hardware requirements ==

For installation and usage consider that Alpine can run on several kinds of devices, from the popular PC machine to video game consoles like the Game Boy Advance and the 3DS, and as such you must check the following of your machine:

** Architectures
** Memory
** Storage
** Peripherals

=== Architectures ===

'''Architecture means kind of computer. The most popular architecture is the misnamed "Intel IBM PC"''' or "i386" which is actually in fact the x86 or x64. There are other supported computer architectures that are not "x86", like mainframes, servers, and embedded devices (such as routers like Sonicwall and Cisco ones). Here are the architectures supported by Alpine:

{| class="wikitable"
|-
! Supported Arch !! Supported since !! Meaning of installation and target architecture
|-
| x86_64 || all || The popular AMD64 compatible 64-bit x86 based machines, i386 is not recommended for newer/latest hardware.
|-
| x86 || all || The all popular 32 bit intel (i386 pc 32bit) and x86_64 (i686 pc 64bit and amd64)compatible (both)
|-
| ppc64le || v3.6 || For the PowerPC devices with pure little-endian mode, mostly for POWER8 and POWER9
|-
| armhf || v3.0 || The newer ARM hard-float for newer, more powerful 32-bit devices alongside 64-bit. Including video games!
|-
| armv7 || v3.9 || The 32-bit ARM only execution state of the ARMv7 devices machines. Including video game consoles!
|-
| aarch64 || v3.5 || The 64-bit ARM only execution state of the ARMv8 device machines. Like Rasberri's
|-
| ppc64le || v3.6 || for 64-bit big-endian PowerPC and Power ISA processors like some MAC computers.
|-
| s390x || v3.6 || For the Super powered IBM mainframes, especially IBM Z and IBM LinuxONE servers.
|}

=== Memory ===

'''Means minimum amount of RAM memory. Need of RAM it depends of the meaning of the installation''', any hardware are supported and there is minimum sizes for:

{| class="wikitable sortable"
|-
! Target Arch !! Minimum RAM to start !! Minimum RAM to install !! Minimum RAM for GUI desktop !! Enough for GUI work
|-
| x86_64 || 512 Megs || 512 Megs || 2 Gigs || 8 Gigs
|-
| x86_32 || 128 Megs || 256 Megs || 1 Gigs || 3 Gigs
|-
| ppc64le || 128 Megs || 256 Megs || 2 Gigs || 8 Gigs
|-
| armhf || 256 Megs || 512 Megs || 1 Gigs || 6 Gigs
|-
| armv7 || 256 Megs || 512 Megs || 1 Gigs || 6 Gigs
|-
| aarch64 || 256 Megs || 512 Megs || 2 Gigs || 8 Gigs
|-
| ppc64le || 256 Megs || 512 Megs || 1 Gigs || 6 Gigs
|-
| s390x || 128 Megs || 256 Megs || 2 Gigs || N/A
|}

=== Storage ===

'''Means any external or internal storage device that can be added after or before install to use''' by the Alpine Linux system. Currently depends of the current linux kernel supported.

'''All the PATA and SATA hard disk drives are supported, also any USB or SD''' card that can be detected by USB BUS by the linux kernel subsystem during install.

=== Peripherals ===

'''Means any external or internal device that can be added after or before install to detectd''' by the Alpine Linux system. Currently depends of the current linux kernel supported.

ISA devices are not supported since 3.8 because kernel drops support.

Almost any GPU are supported, but for advanced features, 3D acceleration are manager by MESA project:

* Intel: mostly any Intel by one exception, intel i810/i815 will lack of features cos only has 4Mb memory, Mesa and Linux drop theit support.
* ATI/AMD, only radeon series with exception of recent two last years respect Alpine release, Rage r128/match64 series has limited support.
* Nvidia: limited; only few are complete supported! not all features are allowed!
* Matrox: not all features are supported, just cos are shipped on most servers.
* Sis: limited features are supported, since code are not updated on Xorg and Linux kernel
* Via: limited features are supported, since openchrome code are not updated on Xorg and Linux kernel

== Software requirements ==

** Media
** Booting
** Storage
** Firmware

=== Media ===

'''Means the files need for dump the install media, and later boot from the target install''' machine, of course downloaded from http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/ or main Download page.

{| class="wikitable"
|-
! Available for !! ISO (for USB, CD/DVD) !! IMG (for Netboot) !! TAR (for ROOTFS, in tar.gz) !! Download links
|-
| x86_64 || YES || YES || N/A || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/x86_64/
|-
| x86 || YES || YES || N/A || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/x86/
|-
| ppc64le || NO || YES || YES || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/ppc64le/
|-
| armhf || NO || YES || YES || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/armhf/
|-
| armv7 || NO || YES || YES || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/armv7/
|-
| aarch64 || YES || YES || YES || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/aarch64/
|-
| mips64 || YES || YES || N/A || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/mips64/
|-
| s390x || YES || YES || N/A || http://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/s390x/
|}

==== Checksum ====

'''Means Commands to verify the checksum and GPG signature of a downloaded image file on different systems, is complete optional!'''. This kind of check are made to verify if the download media ISO (for USB, CD/DVD), IMG (for Netboot) or TAR (for ROOTFS, in tar.gz) file are correct and will work. Just performs that command in your system before use that downloaded file:

{| class="wikitable"
! OS where media was downloaded !! <code>sha265</code> calculation (to be compared manually) !! <code>GPG</code> signature verification
|-
| Linux || <code>sha256sum -c alpine-*.iso.sha256</code> || <code>curl https://alpinelinux.org/keys/ncopa.asc | gpg --import ; <nowiki>gpg --verify alpine-*.iso.asc alpine-*.iso</nowiki></code>
|-
| MACOS || <code>shasum -a 256 alpine-*.iso</code> || - ? -
|-
| BSD || <code>/usr/local/bin/shasum -a 256 alpine-*.iso</code> || - ? -
|}

=== Booting ===

'''Means support for kind of BIOS setup of machine, and where can be media downloaded will be boot''', please for more info check [[Alpine_and_UEFI|Alpine and UEFI]] wiki page.

{| class="wikitable"
|-
! Supported Arch !! Supported BIOS !! Supported Types !! Media Boot Recommended
|-
| x86_64 || Coreboot, Vendor/OEM || BIOS, UEFI || '''USB''', CD/DVD (ISO)
|-
| x86 || Coreboot, Vendor/OEM || BIOS, UEFI || '''USB''', CD/DVD (ISO)
|-
| ppc64le || Coreboot, Vendor/OEM || BIOS, UEFI || '''USB''', CD/DVD (ISO)
|-
| armhf || Uboot, Vendor/OEM || BIOS, UEFI || '''NET''', MINIROOTFS (TAR.GZ)
|-
| armv7 || Uboot, Vendor/OEM || BIOS, UEFI || '''NET''', MINIROOTFS (TAR.GZ)
|-
| aarch64 || ?Coreboot?, Vendor/OEM || BIOS, ?UEFI? || '''USB''', CD/DVD (ISO)
|-
| mips64 || Vendor/OEM || ? || MINIROOTFS (TAR.GZ)
|-
| s390x || Vendor/OEM || BIOS, ?UEFI?|| '''USB''', CD/DVD
|}

If the computer does not automatically boot from the desired device, one needs to bring up the boot menu selection for choosing the media to boot from. Depending on the computer the menu may be accessed by quickly (repeatedly) pressing a key when booting starts, or sometimes it is needed to press the button before starting the computer and keep holding it when it boots. Typical keys are: `F9`-`F12`, sometimes `F7` or `F8`. If these don't bring up the boot menu, it may be necessary to enter the BIOS configuration and adjust the boot settings, for which typical keys are: `Del.` `F1` `F2` `F6` or `Esc.`

=== Space ===

'''This means amount of available space in disk partitions to perform a kind of install''' and of course will depends of type and meaning of your desired install, this are the recommended sizes but depends of the BIOS/UEFI supported you must perform and read the [[Alpine_and_UEFI#Alpine_disk_layout_for_UEFI|Alpine disk layout for UEFI/BIOS at Alpine and UEFI]] wiki page.

{| class="wikitable"
|-
! Minimum sizes !! Partition for BOOT (<code>/boot</code>) !! Partition for ROOT (<code>/</code>) !! Partition for HOME (<code>/home</code>) !! Partition for SWAP (<code>N/A</code>)
|-
| base only || 100 Megs || 500 Megs || 1 Gigs || Optional
|-
| default server || 200 Megs || 2 Gigs || 2 Gigs || 4 Gigs
|-
| default desktop || 250 Megs || 12 Gigs || 80 Gigs || 8 Gigs
|-
| mail server || 200 Megs || 20 Gigs || 20+ Gigs || 8 Gigs
|-
| web server || 200 Megs || 10 Gigs || 20+ Gigs || 8 Gigs
|}

= See Also =

# [[Installation]]
# [[Alpine_newbie#Install|Alpine_newbie Install section]]

[[Category:Installation]]

__FORCETOC__

Alpine Package Keeper

2020-10-06T13:55:39Z

Newbyte: Fix cache maintenance link

{{TOC right}}

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 system. 
'''lbu''' is the tool used to capture the data necessary to restore a system to a previously configured state.

This page documents the [https://git.alpinelinux.org/apk-tools/ apk tool] - See the [[Alpine_local_backup|Alpine Local Backup page]] for the lbu tool.

= Overview =

The '''apk''' tool supports the following operations:

{|
| [[#Add a Package|add]]
| Add new packages or upgrade packages to the running system
|-
| [[#Remove a Package|del]]
| Delete packages from the running system
|-
| fix
| Attempt to repair or upgrade an installed package
|-
| [[#Update the Package list|update]]
| Update the index of available packages
|-
| [[#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
|-
| dot
| Create a [http://graphviz.org/ graphviz] graph description for a given package
|-
| [[#apk_policy|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 <code>.apk</code>, 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 '''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 a USB stick ({{Path|/media/sda1}}) or CD-ROM ({{Path|/media/cdrom}}), your repository file probably looks something like this:

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

{{Cat|/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| A list of public repositories is in [https://git.alpinelinux.org/cgit/aports/tree/main/alpine-mirrors/mirrors.yaml mirrors.yaml] in the alpine-mirrors git repository. Accepted protocols vary.}}

== Repository pinning ==

You can specify additional "tagged" repositories in {{Path|/etc/apk/repositories}}:

{{Cat|/etc/apk/repositories|
http://nl.alpinelinux.org/alpine/v3.7/main
http://nl.alpinelinux.org/alpine/v3.7/community
@edge http://nl.alpinelinux.org/alpine/edge/main
@edgecommunity http://nl.alpinelinux.org/alpine/edge/community
@testing http://nl.alpinelinux.org/alpine/edge/testing
}}

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

{{cmd|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)

== 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.
|-
| <nowiki>-X|--repository REPO</nowiki>
| 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 {{Path|APKINDEX.tar.gz}} from each repository and stores it in the local cache, typically {{Path|/var/cache/apk/}}, {{Path|/var/lib/apk/}} or {{Path|/etc/apk/cache/}}.

{{Cmd|apk update}}



Adding the <code>--update-cache</code>, or for short <code>-U</code> switch to another apk command, as in <code>apk --update-cache upgrade</code> or <code>apk -U add ...</code>, the command has the same effect as first running <code>apk update</code> 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.

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

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

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

{{cmd|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:

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

{{cmd|apk del openssh
apk del openssh openntp vim}}

= Upgrade a Running System =

To get the latest security upgrades and bugfixes available for ''all'' the packages of a running system, first '''update''' the list of available packages and then '''upgrade''' the installed packages:

{{cmd|apk update
apk upgrade
}}

Or, combining the same into one single command:

{{cmd|apk -U upgrade
}}

Here is an example, showing the procedure on a system that has several additional [https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#Repository_pinning repositories pinned]:

# 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 [http://dl-3.alpinelinux.org/alpine/v3.6/main]
v3.6.2-190-ga5d68c47df [http://dl-3.alpinelinux.org/alpine/v3.6/community]
v3.6.0-4618-g0bf77c9821 [http://dl-3.alpinelinux.org/alpine/edge/main]
v3.6.0-4605-g85ed51dd83 [http://dl-3.alpinelinux.org/alpine/edge/community]
v3.6.0-4624-g11f1b9c8ab [http://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 ''-u'' or ''--upgrade'' option of the '''add''' command:

{{cmd|apk update
apk add --upgrade busybox
}}

{{Note|Remember that when you reboot your machine, remote repositories will not be available until after the 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]].}}

To upgrade an running system to a newer release, refer the release notes and [[Upgrading_Alpine]].

= 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: {{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'' or ''--description'' option: {{cmd|apk search -v --description 'NTP' }}

= Information on Packages =

== 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: {{cmd|apk info -a zlib}}

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

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.

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

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

=== Listing installed packages ===

To list all installed packages, use:

<pre>apk info</pre>

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

<pre>apk -vv info|sort</pre>

== apk policy ==

To display the repository a package was installed from and will be updated from, plus any [https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#Repository_pinning tagged] or enabled repositories where it is also offered, if any, for this architecture - its '''policy''':

apk policy ''package''

For example:
<pre>
$ apk policy vlc
vlc policy:
2.2.6-r1:
lib/apk/db/installed
http://dl-3.alpinelinux.org/alpine/v3.7/community
3.0.0_rc2-r1:
@edgecommunity http://dl-3.alpinelinux.org/alpine/edge/community
</pre>

= Additional apk Commands =
In progress...

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

after which a {{cmd|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,

{{cmd|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:

{{cmd|1=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>[https://git.alpinelinux.org/apk-tools/commit/?id=693b4bcdb0f22904a521a7c8ac4f13e697dc4d71 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.

= 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 {{pkg|apk-tools}}. If edge is already [https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#Repository_pinning tagged] in your repositories, then try:

<pre>sudo apk add --upgrade apk-tools@edge</pre>

= =
* [https://www.cyberciti.biz/faq/10-alpine-linux-apk-command-examples/ 10 Alpine Linux apk Command Examples] Vivek Gite 2019

[[Category:Package Manager]]