nyuuzyou/wikis huggingface dataset:
APKBUILD examples:Lua

== Module with Makefile supporting multiple Lua versions ==
pkgname=lua-foo
_rockname=${pkgname#lua-}
...
arch="all"
depends=""
makedepends=""
subpackages=""
...
_luaversions="5.1 5.2 5.3"
for _v in $_luaversions; do
	makedepends="$makedepends lua$_v-dev"
	subpackages="$subpackages lua$_v-${pkgname#lua-}:_subpackage"
done
build() {
	cd "$builddir"
	local lver; for lver in $_luaversions; do
		msg "Building for Lua $lver..."
		make all$lver
	done
}
package() {
	mkdir -p "$pkgdir"
}
_subpackage() {
	local lver="${subpkgname:3:3}"
	pkgdesc="$pkgdesc (for Lua $lver)"
	depends="lua$lver"
	install_if="$pkgname=$pkgver-r$pkgrel lua$lver"
	local rockdir="$subpkgdir/usr/lib/luarocks/rocks-$lver/$_rockname/$pkgver-0"
	cd "$builddir"
	make PREFIX="/usr" DESTDIR="$subpkgdir" install$lver
	mkdir -p "$rockdir"
	echo 'rock_manifest = {}' > "$rockdir"/rock_manifest
}
== Module with simple Makefile ==
pkgname=lua-foo
_rockname=${pkgname#lua-}
...
arch="all"
depends=""
makedepends=""
subpackages=""
...
_luaversions="5.1 5.2 5.3"
for _v in $_luaversions; do
	makedepends="$makedepends lua$_v-dev"
	subpackages="$subpackages lua$_v-${pkgname#lua-}:_subpackage"
done
prepare() {
	default_prepare
	local lver; for lver in $_luaversions; do
		cp -r "$builddir" "$builddir-$lver"
	done
}
build() {
	local lver; for lver in $_luaversions; do
		msg "Building for Lua $lver..."
		make -C "$builddir-$lver"
	done
}
package() {
	mkdir -p "$pkgdir"
}
_subpackage() {
	local lver="${subpkgname:3:3}"
	pkgdesc="$pkgdesc (for Lua $lver)"
	depends="lua$lver"
	install_if="$pkgname=$pkgver-r$pkgrel lua$lver"
	local rockdir="$subpkgdir/usr/lib/luarocks/rocks-$lver/$_rockname/$pkgver-0"
	cd "$builddir-$lver"
	make PREFIX="/usr" DESTDIR="$subpkgdir" install
	mkdir -p "$rockdir"
	echo 'rock_manifest = {}' > "$rockdir"/rock_manifest
}
== Module with rockspec ==
pkgname=lua-foo
_rockname=${pkgname#lua-}
...
arch="all"
depends=""
makedepends=""
subpackages=""
...
_luaversions="5.1 5.2 5.3"
for _v in $_luaversions; do
	makedepends="$makedepends lua$_v-dev luarocks$_v"
	subpackages="$subpackages lua$_v-${pkgname#lua-}:_subpackage"
done
build() {
	cd "$builddir"
	local lver; for lver in $_luaversions; do
		msg "Building for Lua $lver..."
		luarocks-$lver \
			CC="$CC" \
			CFLAGS="$CFLAGS -fPIC" \
			LUA_INCDIR="$(pkg-config --variable=includedir lua$lver)" \
			LUA_LIBDIR="$(pkg-config --variable=libdir lua$lver)" \
			make --tree=./build $_rockname-$pkgver-0.rockspec
	done
}
package() {
	mkdir -p "$pkgdir"
}
_subpackage() {
	local lver="${subpkgname:3:3}"
	pkgdesc="$pkgdesc (for Lua $lver)"
	depends="lua$lver"
	install_if="$pkgname=$pkgver-r$pkgrel lua$lver"
	local rockdir="$subpkgdir/usr/lib/luarocks/rocks-$lver/$_rockname/$pkgver-0"
	local path; for path in lib/lua/$lver share/lua/$lver; do
		mkdir -p "$subpkgdir"/usr/${path%/*}
		mv "$builddir"/build/$path "$subpkgdir"/usr/$path/
	done
	mkdir -p "$rockdir"
	echo 'rock_manifest = {}' > "$rockdir"/rock_manifest
}
Category:Development
Category:Lua
APKBUILD examples:Neovim

== [Draft] Neovim plugin packaging policy ==
See .
=== Name ===
* Must be prefixed with nvim-
* Only have a single nvim- prefix:
** Use nvim-treesitter, instead of nvim-nvim-treesitter
* Omit .nvim suffix:
** Use nvim-telescope, instead of nvim-telescope.nvim
=== Version ===
If there are no tags, upstream should be requested to release.
=== Site ===
Plugins must be installed in "$pkgdir"/usr/share/nvim/site/pack/dist/opt/$pkgname/. This allows users to lazy load apk managed neovim packages using: :packadd $pkgname, or vim.cmd.packadd('$pkgname').
=== Doc ===
If upstream doesn't contain generated helptags, do so in build:
 build() {
 nvim -u NONE -i NONE -e --headless -c "helptags doc" -c quit
 }
amove neovim help files and tags in doc:
 doc() {
 default_doc
 amove usr/share/nvim/site/pack/dist/opt/$pkgname/doc
 }
=== Tests ===
Skipping check is fine if testing a plugin requires vusted (which is not yet packaged):
 options="!check" # requires vusted
=== Example ===
See community/nvim-lspconfig for a complete example.
APKBUILD examples:Perl

depends="perl"
makedepends="perl-dev"
build() {
	cd "$builddir"
	PERL_MM_USE_DEFAULT=1 perl Makefile.PL INSTALLDIRS=vendor || return 1
	make && make test || return 1
}
The files perllocal.pod and .packlist should be deleted
package() {
	cd "$builddir"
	make DESTDIR="$pkgdir" install || return 1
	find "$pkgdir" \( -name perllocal.pod -o -name .packlist \) -delete
}
Category:Development Category:Perl
APKBUILD examples:Python

A lot of Python packages use the setuptools or distutils framework. This mean that the build() and the package() section looks a bit different compared to an application which uses make.
== Considerations ==
=== pkgname ===
Package name for a Python library must be prefixed with py3-. 
For an 'executable' (for example, black, binwalk), you generally don't need to prefix it. 
There’s no exact rule if the prefix should be used for tools and applications written in Python, it varies.
=== arch ===
; noarch : Use for pure Python packages (i.e. without compiled code).
; all (and others) : Use for packages with native extensions (i.e. with compiled code). Do not add python3 to depends= (it's auto-detected via dynamic linking to python library).
=== source ===
Most Python packages are published in PyPI(the Python Package Index).
If the package has a source tarball available in PyPI (that’s true for most packages), and it contains tests (some explicitly remove them from PyPI), you should reference it in source= as:
https://files.pythonhosted.org/packages/source/${_pyname%${_pyname#?}}/$_pyname/$_pyname-$pkgver.tar.gz
where _pyname is the real name of the Python package.
Otherwise, use the normal upstream git tarballs.
== Examples ==
=== pep517 invocation ===
pkgname="py3-foo"
...
depends="py3-bar py3-baz"
makedepends="py3-gpep517 py3-setuptools py3-wheel python3-dev"
checkdepends="py3-pytest"
subpackages="$pkgname-pyc"
...
build() {
	gpep517 build-wheel \
		--wheel-dir dist \
		--output-fd 3 3>&1 >&2
}
check() {
	python3 -m venv --clear --system-site-packages testenv
	testenv/bin/python3 -m installer dist/*.whl
	testenv/bin/python3 -m pytest
}
package() {
	python3 -m installer -d "$pkgdir" \
		dist/*.whl
}
Depending on the build-backend in the pyproject.toml, you might need py3-setuptools or py3-flit-core or py3-poetry-core or py3-hatchling at build time. If a project specifies literally flit or poetry, patch it to use the -core variant.
Category:Development Category:Python
APKBUILD examples:Ruby

gem is the standard way to install Ruby packages.
build() {
 mkdir -p "$_builddir" || return 1
 local _gemdir="$(ruby -rubygems -e'puts Gem.default_dir')"
 gem install $_realname -v $pkgver -i "$_builddir"$_gemdir \
		--ignore-dependencies --verbose \
		--no-rdoc \
		--no-ri \
		|| return 1
	rm -rf "$_builddir"$_gemdir/cache/
}
package() {
 mkdir -p "$pkgdir" || return 1
 cp -ra "$_builddir"/* "$pkgdir"/ || return 1
}
Category:Development Category:Ruby
APKBUILD examples:Special Subpackages Languages

To keep packages small, languages files (LC_MESSAGES) are places in a seperate -lang subpackages.
abuild is throwing a warning if it detects translation.
>>> WARNING: package*: Found /usr/share/locale. Maybe add $pkgname-lang to subpackages?
Please note that some packages will automatically detect NLS if gettext-dev is installed at build time. If gettext-dev is not a direct or indirect dependency then should most likely no -lang be needed.
Category:Development
APKBUILD examples:Subpackages

Consider the following APKBUILD snippet:
It will ...
* create the following 5 packages:
# foo (main)
# foo-dev (sub)
# foo-doc (sub)
# py-foo (sub)
# libfoo (sub)
* using the following 5 package functions (respectively) to fill them with files:
# package(): will be provided by the user (and can make use of the $pkgdir variable).
# dev(): will be provided by abuild unless we override it, by providing our own dev() function (which can make use of the $subpkgdir variable).
# doc(): will be provided by abuild unless we override it, by providing our own doc() function (which can make use of the $subpkgdir variable).
# pysub(): will be provided by the user (and can make use of the $subpkgdir variable).
# libfoo(): will be provided by the user (and can make use of the $subpkgdir variable).
Category:Development
APKBUILD versions

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.
* Alpine Edge = abuild 3.1.0 
* Alpine 3.7 = abuild 3.1.0 
* Alpine 3.6 = abuild 3.0.0_rc2 
* Alpine 3.5 = abuild 2.29.0 
* Alpine 3.4 = abuild 2.27.1 
* Alpine 3.3 = abuild 2.25.0_rc1 
* Alpine 3.2 = abuild 2.22.0 
* Alpine 3.1 = abuild 2.21.0 
* Alpine 3.0 = abuild 2.20.1 
* Alpine 2.7 = abuild 2.18.0 
* Alpine 2.6 = abuild 2.14.3 
* Alpine 2.5 = abuild 2.13.1 
* Alpine 2.4 = abuild 2.12.1 
* Alpine 2.3 = abuild 2.11.2 
* Alpine 2.2 = abuild 2.9.2 
* Alpine 2.1 = abuild 2.5 
* Alpine 2.0 = abuild 2.5 
* Alpine 2.0 = abuild 2.5 
* Alpine 1.10 = abuild 2.1 
* Alpine 1.9 = abuild 2.0.1 
Category:Development
Abuild and Helpers

The package provides scripts necessary for creating packages for Alpine Linux. It also implements functionality for building packages as well as additional commands and options for package maintenance. For package development and maintenance, it is recommended to install the meta package, which will install the package in addition to other relevant tools.
The git repository always contains the latest version of the scripts, example-files, and makefiles.
== Setting up the build environment ==
== Building packages ==
=== Basic usage ===
If you just want to build a package from an APKBUILD file, only two command are needed. Both commands operate on an APKBUILD file in the current directory, so you should cd into the directory before running them.
* abuild checksum: updates the checksums for source files.
* abuild -r: builds the package.
The manual page (available via man abuild) describes all options and commands for abuild.
=== Building in a chroot ===
== Bumping a package version ==
The tool abump is a utility to bump pkgver in APKBUILD files if the package gets an update to a newer upstream release. abump will update the package's pkgver, rebuild it and create a new commit with the resulting changes.
The manual page (available via man abump) describes all options for abump.
== Updating a package release ==
If you want to bump or reset the pkgrel value of your APKBUILD or test your APKBUILD files, apkgrel can assist you.
apkgrel options
* -a Add 1 to current pkgrel
* -f Force, even if given files are not in proper format
* -h Show this help
* -s Set pkgrel to NUM
* -t Only verify that files are in proper format
* -z Set pkgrel to 0
== Generating new APKBUILDs ==
=== newapkbuild ===
=== apkbuild-cpan ===
=== apkbuild-pypi ===
== Signing packages and indexes ==
=== abuild-sign ===
=== abuild-tar ===
=== buildrepo ===
Aerc

aerc is a terminal email client (MUA) originally written by ~sircmpwn and now maintained by ~rjarry. It supports multiple accounts, mail synchronisation, GPG integration and more.
== Installation ==
aerc is available in the Community repository.
== Configuration ==
Configuration for aerc is stored in , with falling back to if it is unset.
Settings specific to accounts (e.g. IMAP configuration) are stored in which should only be readable and writable by the owning user (permissions 600) as it may store sensitive data like passwords in clear text.
An example account configration using msmtp for sending email and mbsync for fetching email to a local maildirpp store could look like this:
The full configuration file format reference can be found in aerc-accounts(5).
== Documentation ==
aerc is extensively documented in its man pages. Consult aerc-tutorial(7) as a starting point.
== See also ==
* aerc source repository
* aerc wiki
* aerc on the ArchWiki
Category:Mail
Category:Software
Algo 8180 Provisioning With ACF

= Overview =
This page describes how to provision Algo 8180 devices using SIP Provisioning On Alpine Linux based upon the ACF web interface. It is supported starting with Alpine Linux 3.2.
= Setup Procedure=
== 1. Install provisioning server ==
First, install the provisioning server according to the instructions at this page.
== 2. Install firmware package ==
The latest supported firmware is included in a package:
 apk add acf-provisioning-algo
== 3. Configure init.cfg ==
The Algo will override ALL parameters when it is provisioned. If parameters are not provided by the provisioning server, they will be reset to default. Since not all parameters are included in the provisioning database, they must be configured statically in /var/www/provisioning/htdocs/Algo/init.cfg. You can use /var/www/provisioning/htdocs/Algo/init.cfg.sample as a starting point. You will probably need to modify the network configuration and provisioning server IP.
 cp /var/www/provisioning/htdocs/Algo/init.cfg.sample /var/www/provisioning/htdocs/Algo/init.cfg
== 4. Configure the Algo 8180 to connect to the provisioning server ==
Unfortunately, the DHCP option 66 does not seem to work in our testing. So, you must manually configure the Algo to connect to the provisioning server. Once you get the Algo device connected to the network, follow these steps:
*MENU Advanced Settings > Provisioning
**Provisioning Mode: Enabled
**Server Method: Static
**Static Server: Enter the IP address or FQDN of the provisioning server
**Download Method: HTTP
**Config Download Path: Algo
**Firmware Download Path: Algo
Category:ACF
Alpine ACF Skins

= ACF Skins =
ACF has support for multiple skins.Only a few skins are available. Feel free to contribute by programming css-stylesheets for ACF. 
== Directory Structure ==
Sample skins are located in the /usr/share/acf/www/skins/ directory. User-modifiable skins can be added to the /etc/acf/skins/ directory. Each skin is located in its own subdirectory and contains one or more of the following files:
* 'skin'.css - the main CSS file for the skin
* 'skin'-ie.css - Internet Explorer-specific CSS file (loaded in addition to 'skin'.css)
* 'skin'.js - javascript file for the skin
=== Images ===
It is common for skins to include image files. Skin-specific image files should be located in the skin subdirectory. Please see the sample skins for how to include images.
The acf-skin package also includes a variety of tango images located in the static/tango directory.
=== Templates ===
As of acf-core-0.15.1, skins can also include template files. The acf_www-controller will look in the following locations for skin-specific templates before searching /usr/share/acf:
* 'skindirectory'/template-'controller'-'action'-'viewtype'.lsp
* 'skindirectory'/template-'controller'-'viewtype'.lsp
* 'skindirectory'/template-'action'-'viewtype'.lsp
* 'skindirectory'/template-'viewtype'.lsp
For example, the acf_www-controller will check the following locations for action /acf-util/skins/read with viewtype 'html' while using skin 'wik':
* /usr/share/acf/www/skins/wik/template-skins-read-html.lsp
* /usr/share/acf/www/skins/wik/template-skins-html.lsp
* /usr/share/acf/www/skins/wik/template-read-html.lsp
* /usr/share/acf/www/skins/wik/template-html.lsp
== Sample Skins ==
Some example skins are available: 
*/usr/share/acf/www/skins/alps/ 
*/usr/share/acf/www/skins/cloud/ 
*/usr/share/acf/www/skins/ice/ 
*/usr/share/acf/www/skins/snow/
*/usr/share/acf/www/skins/wik/ 
== How To Contribute ==
Make a new skin folder. 
 mkdir -p /etc/acf/skins/myskin
Create a css file called as the folder. 
 touch /etc/acf/skins/myskin/myskin.css
Now you can start editing your myskin.css.If you have ACF running on the computer, you can browse to https://<hostname>/cgi-bin/acf/acf-util/skins/read and switch to your new skin (called myskin) and see the results of your changes. 
Pack your myskin folder, containing your css file (and images, if there are any).Send this patch to acf@lists.alpinelinux.org (Note: Don't forget to subscribe before sending your patch) 
Category:ACF Category:Lua
Alpine Release Testing Checklist

Those tests should be run before an Alpine release.
== CD Install ==
#Boot from CDrom
#login as root at the prompt
# 
# 
# 
# A successful boot up will show the hostname and will require the password set during setup-alpine
# Install openssl for encryption 
# 
# You should get an error saying an unencrypted apkpovl already exist. Use the -d option to replace it with the encrypted apkovl.
# 
# 
# Password for apkovl should be prompted for upon boot up
Tested releases 	Hardware used 	Notes
alpine-1.10_rc3 	Qemu 	
alpine-1.10_rc3 	1.7 ghz P4 - Asus P4SC - 512mb DDR-2100	
alpine-mini-1.10_rc3	Qemu 	
== USB Install ==
#Boot from USB
#login as root at the prompt
# 
# 
# 
# A successful boot up will show the hostname and will require the password set during setup-alpine
# Install openssl for encryption 
# 
# You should get an error saying an unencrypted apkpovl already exist. Use the -d option to replace it with the encrypted apkovl.
# 
# 
# Password for apkovl should be prompted for upon boot up
Tested releases	Hardware used	Issues
release here 	hardware here	issues here
== HDD Install ==
=== Standard ===
#Boot from CDrom
#login as root at the prompt
# 
# 
#reboot and remove the cdrom
#verify that you boot from harddisk (Should say extlinux during boot)
#verify it boots up properly and give you a login prompt
=== With raid ===
#Boot from CDrom
#login as root at the prompt
# 
# 
#reboot and remove the cdrom
#verify that you boot from harddisk (Should say extlinux during boot)
#verify it boots up properly and give you a login prompt
Tested releases	Hardware used	Issues
release here 	hardware here	issues here
Category:Development
Alpine SCST

==alpine-scst-110210-x86_64.iso==
* alpine-base-2.1.0_git20101221-r0.apk
* alpine-baselayout-2.0_rc1-r2.apk
* alpine-conf-2.5.5-r1.apk
* apk-tools-2.0.7-r6.apk
* bbsuid-0.5-r1.apk
* bkeymaps-1.13-r0.apk
* busybox-1.18.2-r0.apk
* busybox-initscripts-2.0-r14.apk
* bwm-ng-0.6-r2.apk
* device-mapper-2.02.83-r0.apk
* e2fsprogs-1.41.14-r0.apk
* ethtool-6-r1.apk
* hdparm-9.36-r0.apk
* htop-0.8.3-r1.apk
* iscsi-scst-2.0.0-r2.apk
* libblkid-2.18-r1.apk
* libc0.9.32-0.9.32_rc2-r0.apk
* libcom_err-1.41.14-r0.apk
* libcrypto1.0-1.0.0d-r0.apk
* libgcc-4.5.2-r2.apk
* libssl1.0-1.0.0d-r0.apk
* libstdc++-4.5.2-r2.apk
* libuuid-2.18-r1.apk
* linux-firmware-2.6.36.3-r0.apk
* linux-scst-2.6.36.3-r0.apk
* lvm2-2.02.83-r0.apk
* mailx-8.1.1-r0.apk
* mdadm-3.1.4-r0.apk
* mkinitfs-2.3.0-r2.apk
* ncurses-5.7-r3.apk
* openrc-0.6.1-r5.apk
* openssh-5.6_p1-r1.apk
* openssh-client-5.6_p1-r1.apk
* parted-2.3-r0.apk
* perl-5.12.3-r0.apk
* readline-6.1.002-r2.apk
* scstadmin-2.0.0-r2.apk
* smartmontools-5.40-r0.apk
* ssmtp-2.64-r4.apk
* uclibc-utils-0.9.32_rc2-r0.apk
* util-linux-ng-2.18-r1.apk
* xfsprogs-3.1.4-r0.apk
* zlib-1.2.5-r1.apk
Category:ISO
Alpine Security and Rescue

The Alpine Security flavor (or short Alpine Security) provides a toolset to work on security auditing, forensics, system rescue, and teaching security testing methodologies. The tool list contains packages for code analysis, forensics and data recovery, reconnaissance, network statistics, VoIP, wireless lan, and IDS. The focus of Alpine Rescue is system maintenance, backup, and rescue tasks.
The target is not to start a competition with the Fedora Security Lab or Kali. But rather make it easy to use the particular tools with Alpine Linux in a small, non GUI, and Busybox-based system.
== Package list ==
* Alpine Security Flavor
* Alpine Rescue Flavor
With the simple python-based config-builder script those pages can be transformed into a plaintext file for the usage with alpine-iso. For details please read this page.
== Vulnerable test systems ==
Alpine Linux is a security-oriented Linux distribution. This made it a perfect base for hosting vulnerable web applications. In the list below you will find documentation about the installation and setup of such applications.
* Damn Vulnerable Web Application (DVWA)
* SQLol
* NOWASP (Mutillidae)
* PHP Shell
* bWAPP
Category:ISO Category:Security
Alpine Source Map by boot sequence

= Alpine Source Map by boot sequence =
There are many different running mode/environment for Alpine. Here I try to describe what I've learned by tracing the source code.
== Boot Sequence ==
A typical boot sequence of Alpine is:
# Hardware BIOS
# Boot Loader (syslinux's isolinux)
# Initramfs (linux-grsec)
# Kernel (linux-grsec)
# Init System(openrc)
# Shell(busybox's ash)
For Embedded System:
# Boot Loader(UBOOT)
# Kernel
# Init System
# Shell
For docker:
# Shell (docker image https://hub.docker.com/_/alpine/)
=== syslinux ===
The 'syslinux.cfg' of in put in https://github.com/alpinelinux/alpine-iso/blob/master/Makefile
=== initramfs ===
You can extract it by gzip -dc initramfs-grsec|cpio -vid
You could remove 'quiet' and add 'debug' flag on kernel boot options to display more debug information.
The source of init could be found by apk info -W /usr/share/mkinitfs/initramfs-init https://github.com/alpinelinux/mkinitfs
=== linux-grsec ===
The package kernel into ISO file method in https://github.com/alpinelinux/alpine-iso/blob/master/Makefile.
The source of kernel in 
=== openrc ===
The Alpine customized scripts are in https://github.com/alpinelinux/aports/tree/master/main/openrc
# /etc/inittab https://github.com/alpinelinux/aports/blob/master/main/alpine-baselayout/inittab
# /etc/runlevels/boot/bootmisc https://github.com/OpenRC/openrc/blob/master/init.d/bootmisc.in
=== shell ===
By 'apk info -W /etc/profile', we know the default profile is customized in https://github.com/alpinelinux/aports/tree/master/main/alpine-baselayout
== Developer Environment ==
=== Trace code in docker ===
In any modern Linux distribution, run docker will let you get the same developer environment.
 docker run -it --name alpine alpine /bin/sh
Create the build/development inside docker
 apk update
 apk add tmux vim diffutils # my tools
 apk add alpine-sdk xorriso syslinux
 adduser YOUR_ID # There are some build scripts can't work under 'root' account.
 su - YOUR_ID
 abuild-keygen -i -a
Build one package sample(eg. openrc)
 git clone https://github.com/alpinelinux/aports
 cd aports/main/openrc # change this line to the package which you want to change
 abuild -r
 ls -l ~/packages/x86_64/openrc*
When you shut down your PC, you can recall the docker 'alpine' container by
 docker start alpine
 docker attach alpine
=== Test ===
* Test ISO file
 qemu-system-x86_64 -enable-kvm -localtime -m 512M -vga std \
 -drive file=YOUR_ISO_FILE ,cache=none,if=virtio
* Test Package in docker
To make sure you got the same environment of default package environment, just use docker.
 docker run --it --rm --name alpine-test alpine /bin/sh
 apk update
 # on other window copy your new apk into the 'alpine-test' container
 docker cp foo.apk alpine-test:/tmp
 # back to 'alpine-test' container
 apk fix /tmp/foo.apk
Category:Development