https://wiki.alpinelinux.org/w/api.php?action=feedcontributions&user=Dlin&feedformat=atomAlpine Linux - User contributions [en]2024-03-28T22:51:17ZUser contributionsMediaWiki 1.40.0https://wiki.alpinelinux.org/w/index.php?title=APKBUILD_Reference&diff=13153APKBUILD Reference2017-02-28T06:45:49Z<p>Dlin: default_prepare</p>
<hr />
<div>APKBUILDs are the scripts that are created in order to build Alpine packages using the [[abuild]] tool.<br />
<br />
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]].<br />
<br />
= Legend =<br />
The following notes will assist you in understanding this document.<br />
<br />
In description text:<br />
* If a variable is not prefixed with a ''$'', it will be represented by italics (i.e., ''srcdir'' ).<br />
* Functions will also be represented by italics, but will also end with a pair of parentheses (i.e., ''build()'' ).<br />
* Shell commands will be represented <code>like this</code>.<br />
<br />
<br />
= Variables =<br />
{{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.}}<br />
{{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'').}}<br />
<br />
== abuild-defined variables ==<br />
The following variables are defined by abuild:<br />
<br />
==== startdir ====<br />
: The directory where the APKBUILD script is.<br />
==== srcdir ====<br />
: The directory where sources, from the ''source'' variable, are downloaded to and unpacked to.<br />
==== pkgdir ====<br />
: 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.<br />
==== subpkgdir ====<br />
: This directory should receive the files for a subpackage. This variable should only be used from subpackage functions.<br />
==== builddir ====<br />
: 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.<br />
<br />
<br />
== User-defined variables ==<br />
The following variables should be defined by the user:<br />
==== arch ====<br />
: Package architecture(s) to build for. Can be one of: '''x86, x86_64, armhf, aarch64, all''', or '''noarch''', where '''all''' means all architectures, and '''noarch''' means it's architecture-independent (e.g., a pure-python package).<br />
: {{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'''.}}<br />
==== depends ====<br />
: Run-time dependency package(s) that are not shared-object dependencies. Shared objects dependencies are auto-detected and should not be specified here.<br />
==== depends_dev ====<br />
: Run-time dependency package(s) for the '''$pkgname-dev''' subpackage.<br />
<br />
: {{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).}}<br />
==== giturl ====<br />
:Git repository from which <code>abuild checkout</code> checks out. You can checkout a specific branch in git by adding <code>-b $branch</code>.<br />
==== install ====<br />
: 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.<br />
<br />
: First, a few notes regarding install scripts:<br />
<blockquote>{{Note|When using install scripts, ''$install'' should be included in ''source'' so that checksums can be generated and used for the install scripts specified in ''install''. For example:<br />
<pre><br />
install="$pkgname.pre-install $pkgname.post-install"<br />
source="http://....<br />
$install"<br />
</pre>}}<br />
{{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><br />
<br />
The following are the different types of install scripts in detail:<br />
<br />
===== $pkgname.pre-install =====<br />
: 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:<br />
<blockquote><pre><br />
#!/bin/sh<br />
<br />
addgroup -S clamav 2>/dev/null<br />
adduser -S -D -H -s /bin/false -G clamav -g clamav clamav 2>/dev/null<br />
<br />
exit 0<br />
</pre><br />
{{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><br />
<br />
===== $pkgname.post-install =====<br />
: This script is executed ''after installing'' the package.<br />
<br />
===== $pkgname.pre-upgrade =====<br />
: 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.<br />
<br />
===== $pkgname.post-upgrade =====<br />
: This script is executed ''after upgrading/downgrading/reinstalling'' the package.<br />
<br />
===== $pkgname.pre-deinstall =====<br />
: This script is executed ''before uninstalling'' the package.<br />
: {{Note|If the script exits with failure, <code>apk</code> will not uninstall the package.}}<br />
<br />
===== $pkgname.post-deinstall =====<br />
: This script is executed ''after uninstalling'' the package.<br />
<br />
==== install_if ====<br />
:install_if can be used when a package needs to be installed when some packages are already installed or are in the dependency tree. As example we could take open-vm-tools. Currently it contains the userspace tools and separate packages for the kernel modules (grsec and vserver). When we install the userspace tools, apk should automatically install the correct kernel modules and will need to figure out for which kernel. This is where install_if jumps in. For any of the kernel modules package we would use:<br />
<br />
:<pre>install_if="linux-${_flavor}=${_kernelver} open-vm-tools"</pre><br />
<br />
:This will automatically install the package when the specified packages are installed or are in dependency tree.<br />
<br />
==== license ====<br />
: License(s) for the package.<br />
==== makedepends ====<br />
: Build-time dependency package(s).<br />
==== md5sums ====<br />
: 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.<br />
==== options ====<br />
: Build-time options for the package. Can be: '''!strip''' - to avoid stripping symbols from binaries.<br />
==== pkgdesc ====<br />
: A brief, one-line description of what the package does.<br />
<br />
: Here's an example from the OpenSSH client package:<br />
: <pre>pkgdesc="Port of OpenBSD's free SSH release - client"</pre><br />
==== pkggroups ====<br />
: 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.<br />
==== pkgname ====<br />
: The name of the package. All letters should be lowercase.<br />
: {{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.}}<br />
<br />
==== pkgrel ====<br />
: 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''.<br />
==== pkgusers ====<br />
: 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.<br />
==== pkgver ====<br />
: The version of the software being packaged.<br />
==== provides ====<br />
: List of package names (and optionally version info) this package provides.<br />
<br />
: 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.<br />
<br />
: 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.<br />
==== replaces ====<br />
: Package(s) that this package replaces. This package will "take over" files owned by packages listed in the ''replaces'' variable. This is useful when files move from one package to another, or when a package gets renamed.<br />
==== replaces_priority ====<br />
: The priority of the replaces. If multiple packages replace each other, then will the package with highest ''replaces_priority'' win.<br />
==== source ====<br />
: 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.<br />
<br />
: Here are few things to note:<br />
<br />
:* 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:<br />
:: {{Cmd|abuild checksum}}<br />
:: {{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.}}<br />
<br />
:* When the remote file is hosted at SourceForge, it's best to specify the special mirrors link used by SourceForge:<br />
:: <pre>http://downloads.sourceforge.net/$pkgname/$pkgname-$pkgver.tar.gz</pre><br />
:: (or similar depending on the package).<br />
<br />
:* 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:<br />
:: <pre>http://oss.example.org/?get=software&ver=1.0</pre><br />
:: or when the filename is braindead, like githubs' download tags:<br />
:: <pre>https://github.com/software/software/archive/v$pkgver.tar.gz</pre><br />
:: The above two examples needs a target filename prefix:<br />
:: <pre>$pkgname-$pkgver.tar.gz::http://oss.example.org/?get=software&ver=$pkgver</pre><br />
:: and:<br />
:: <pre>$pkgname-$pkgver.tar.gz::https://github.com/software/software/archive/v$pkgver.tar.gz</pre><br />
<br />
:* abuild currently supports the following protocols for remote file retrieval:<br />
:** http<br />
:** https<br />
:** ftp<br />
<br />
:* abuild currently supports the following archive types/archive file extensions:<br />
:** .tar.gz / .tgz<br />
:** .tar.bz2<br />
:** .tar.lzma<br />
:** .tar.xz<br />
:** .zip<br />
<br />
:: {{Note|Legacy APKBUILD scripts define ''source'' variable as "saveas-[brain-dead-url]/[target-filename]" format instead of the modern [target-filename]::[brain-dead-url].<br />''BAD'': source&#61;"saveas-http://releases.ddvtech.com/download.php?pack&#61;libmist_dist&ver&#61;RC/$pkgname-$pkgver.tar.gz"<br />''GOOD'': source&#61;$pkgname-$pkgver.tar.gz::http://releases.ddvtech.com/download.php?pack&#61;libmist_dist&ver&#61;RC"}}<br />
<br />
==== subpackages ====<br />
: 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''.<br />
<br />
: The split function can be specified in 1 of 3 different methods:<br />
:# subpkgname:'''splitfunc'''<br />
:# $pkgname-'''splitfunc'''<br />
:# '''splitfunc'''<br />
<br />
: {{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'''.}}<br />
<br />
: {{Tip|For more information, see the [[APKBUILD_examples:Subpackages|Subpackages example]].}}<br />
<br />
==== triggers ====<br />
: Apk-tools can "monitor" directories and execute a trigger if any package installed/uninstalled any file in the monitored dir. The triggers are always execute after the apk action (install, uninstall, upgrade).<br />
<br />
: 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.<br />
<br />
: The '''triggers''' variable must include the triggers for subpackages too if they have any.<br />
<br />
: It is possible to use wildcards (*) in the dir list.<br />
<br />
==== url ====<br />
: The homepage for the package. This is to help users find upstream documentation and other information regarding the package.<br />
<br />
= Functions =<br />
{{Note|All functions 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.}}<br />
<br />
== abuild-defined functions ==<br />
The following functions are provided by abuild and can be overridden:<br />
<br />
==== fetch() ====<br />
: Downloads remote sources listed in ''source'' to ''SRCDEST'' (''SRCDEST'' is configured in ''/etc/abuild.conf'') and creates symlinks in ''$srcdir''.<br />
==== unpack() ====<br />
: Unpacks .tgz, .tar.gz, .tar.bz2, .tar.lzma, .tar.xz, and .zip archives in ''$srcdir'' to ''$srcdir''.<br />
==== dev() ====<br />
: Subpackage function for the '''$pkgname-dev''' package. Without specifying a custom ''dev()'' function, abuild will call it's internal ''dev()'' function, which in turn calls ''default_dev()'', which will move ''"$pkgdir"/usr/include'', ''*.a'', ''*.la'' and similar files to ''$subpkgdir''.<br />
==== doc() ====<br />
: Subpackage function for the '''$pkgname-doc''' package. Without specifying a custom ''doc()'' function, abuild will call it's internal ''doc()'' function, which in turn calls ''default_doc()'', which will move ''"$pkgdir"/usr/share/doc'', ''"$pkgdir"/usr/share/man'' and similar to ''$subpkgdir''.<br />
<br />
== User-defined functions ==<br />
The following functions should be defined by the user: <br />
<br />
==== prepare() ====<br />
: '''''Optional''.''' Used for build preparation: patches, etc, should be applied here. This function is available for your convenience. It is better to use "default_prepare || return" to handle *.patch file, and the patch file should always be prepared as -p1 format.<br />
==== build() ====<br />
: '''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><br />
==== package() ====<br />
: '''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><br />
<br />
{{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.}}<br />
<br />
= Examples =<br />
The [[APKBUILD examples]] page will assist you in understanding how to create an APKBUILD.<br />
<br />
[[Category:Development]]</div>Dlinhttps://wiki.alpinelinux.org/w/index.php?title=Alpine_Source_Map_by_boot_sequence&diff=13068Alpine Source Map by boot sequence2016-11-29T07:07:42Z<p>Dlin: find the initramfs source</p>
<hr />
<div>= Alpine Source Map by boot sequence =<br />
<br />
{{Draft|Alternate message.}}<br />
<br />
There are many different running mode/environment for Alpine. Here I try to describe what I've learned by tracing the source code.<br />
<br />
== Boot Sequence ==<br />
<br />
A typical boot sequence of Alpine is:<br />
<br />
# Hardware BIOS<br />
# Boot Loader (syslinux's isolinux)<br />
# Initramfs (linux-grsec)<br />
# Kernel (linux-grsec)<br />
# Init System(openrc)<br />
# Shell(busybox's ash)<br />
<br />
For Embedded System:<br />
<br />
# Boot Loader(UBOOT)<br />
# Kernel<br />
# Init System<br />
# Shell<br />
<br />
For docker:<br />
# Shell (docker image https://hub.docker.com/_/alpine/)<br />
<br />
=== syslinux ===<br />
The 'syslinux.cfg' of {{Pkg|syslinux}} in put in https://github.com/alpinelinux/alpine-iso/blob/master/Makefile<br />
<br />
=== initramfs ===<br />
You can extract it by <code>gzip -dc initramfs-grsec|cpio -vid</code><br />
You could remove 'quiet' and add 'debug' flag on kernel boot options to display more debug information.<br />
The source of init could be found by <code>apk info -W /usr/share/mkinitfs/initramfs-init</code> https://github.com/alpinelinux/mkinitfs<br />
<br />
=== linux-grsec ===<br />
The package kernel into ISO file method in https://github.com/alpinelinux/alpine-iso/blob/master/Makefile.<br />
<br />
The source of kernel in {{Pkg|linux-grsec}}<br />
<br />
=== openrc ===<br />
The Alpine customized scripts are in https://github.com/alpinelinux/aports/tree/master/main/openrc<br />
<br />
# /etc/inittab https://github.com/alpinelinux/aports/blob/master/main/alpine-baselayout/inittab<br />
# /etc/runlevels/boot/bootmisc https://github.com/OpenRC/openrc/blob/master/init.d/bootmisc.in<br />
<br />
<br />
=== shell ===<br />
By 'apk info -W /etc/profile', we know the default profile is customized in {{Pkg|alpine-baselayout}} https://github.com/alpinelinux/aports/tree/master/main/alpine-baselayout<br />
<br />
== Developer Environment ==<br />
<br />
=== Trace code in docker ===<br />
In any modern Linux distribution, run docker will let you get the same developer environment.<br />
docker run -it --name alpine alpine /bin/sh<br />
<br />
<br />
Create the build/development inside docker<br />
apk update<br />
apk add tmux vim diffutils # my tools<br />
apk add alpine-sdk xorriso syslinux<br />
adduser YOUR_ID # There are some build scripts can't work under 'root' account.<br />
su - YOUR_ID<br />
abuild-keygen -i -a<br />
<br />
Build one package sample(eg. openrc)<br />
git clone https://github.com/alpinelinux/aports<br />
cd aports/main/openrc # change this line to the package which you want to change<br />
abuild -r<br />
ls -l ~/packages/x86_64/openrc*<br />
<br />
When you shut down your PC, you can recall the docker 'alpine' container by<br />
docker start alpine<br />
docker attach alpine<br />
<br />
<br />
=== Test ===<br />
* Test ISO file<br />
qemu-system-x86_64 -enable-kvm -localtime -m 512M -vga std \<br />
-drive file=YOUR_ISO_FILE ,cache=none,if=virtio<br />
<br />
* Test Package in docker<br />
To make sure you got the same environment of default package environment, just use docker.<br />
docker run --it --rm --name alpine-test alpine /bin/sh<br />
apk update<br />
<br />
# on other window copy your new apk into the 'alpine-test' container<br />
docker cp foo.apk alpine-test:/tmp<br />
<br />
# back to 'alpine-test' container<br />
apk fix /tmp/foo.apk<br />
<br />
[[Category:Development]]</div>Dlinhttps://wiki.alpinelinux.org/w/index.php?title=Alpine_Source_Map_by_boot_sequence&diff=13067Alpine Source Map by boot sequence2016-11-29T04:59:12Z<p>Dlin: /* Boot Sequence */</p>
<hr />
<div>= Alpine Source Map by boot sequence =<br />
<br />
{{Draft|Alternate message.}}<br />
<br />
There are many different running mode/environment for Alpine. Here I try to describe what I've learned by tracing the source code.<br />
<br />
== Boot Sequence ==<br />
<br />
A typical boot sequence of Alpine is:<br />
<br />
# Hardware BIOS<br />
# Boot Loader (syslinux's isolinux)<br />
# Initramfs (linux-grsec)<br />
# Kernel (linux-grsec)<br />
# Init System(openrc)<br />
## /etc/inittab https://github.com/alpinelinux/aports/blob/master/main/alpine-baselayout/inittab<br />
## /etc/runlevels/boot/bootmisc https://github.com/OpenRC/openrc/blob/master/init.d/bootmisc.in<br />
## ...<br />
# Shell(busybox's ash)<br />
<br />
For Embedded System:<br />
<br />
# Boot Loader(UBOOT)<br />
# Kernel<br />
# Init System<br />
# Shell<br />
<br />
For docker:<br />
# Shell (docker image https://hub.docker.com/_/alpine/)<br />
<br />
=== syslinux ===<br />
The 'syslinux.cfg' of {{Pkg|syslinux}} in put in https://github.com/alpinelinux/alpine-iso/blob/master/Makefile<br />
<br />
=== linux-grsec ===<br />
The package kernel into ISO file method in https://github.com/alpinelinux/alpine-iso/blob/master/Makefile.<br />
<br />
The source of kernel in {{Pkg|linux-grsec}}<br />
<br />
=== openrc ===<br />
The Alpine customized scripts are in https://github.com/alpinelinux/aports/tree/master/main/openrc<br />
<br />
=== shell ===<br />
By 'apk info -W /etc/profile', we know the default profile is customized in {{Pkg|alpine-baselayout}} https://github.com/alpinelinux/aports/tree/master/main/alpine-baselayout<br />
<br />
== Developer Environment ==<br />
<br />
=== Trace code in docker ===<br />
In any modern Linux distribution, run docker will let you get the same developer environment.<br />
docker run -it --name alpine alpine /bin/sh<br />
<br />
<br />
Create the build/development inside docker<br />
apk update<br />
apk add tmux vim diffutils # my tools<br />
apk add alpine-sdk xorriso syslinux<br />
adduser YOUR_ID # There are some build scripts can't work under 'root' account.<br />
su - YOUR_ID<br />
abuild-keygen -i -a<br />
<br />
Build one package sample(eg. openrc)<br />
git clone https://github.com/alpinelinux/aports<br />
cd aports/main/openrc # change this line to the package which you want to change<br />
abuild -r<br />
ls -l ~/packages/x86_64/openrc*<br />
<br />
When you shut down your PC, you can recall the docker 'alpine' container by<br />
docker start alpine<br />
docker attach alpine<br />
<br />
<br />
=== Test ===<br />
* Test ISO file<br />
qemu-system-x86_64 -enable-kvm -localtime -m 512M -vga std \<br />
-drive file=YOUR_ISO_FILE ,cache=none,if=virtio<br />
<br />
* Test Package in docker<br />
To make sure you got the same environment of default package environment, just use docker.<br />
docker run --it --rm --name alpine-test alpine /bin/sh<br />
apk update<br />
<br />
# on other window copy your new apk into the 'alpine-test' container<br />
docker cp foo.apk alpine-test:/tmp<br />
<br />
# back to 'alpine-test' container<br />
apk fix /tmp/foo.apk<br />
<br />
[[Category:Development]]</div>Dlinhttps://wiki.alpinelinux.org/w/index.php?title=Alpine_Source_Map_by_boot_sequence&diff=13066Alpine Source Map by boot sequence2016-11-29T03:21:11Z<p>Dlin: Created page with "= Alpine Source Map by boot sequence = {{Draft|Alternate message.}} There are many different running mode/environment for Alpine. Here I try to describe what I've learned by..."</p>
<hr />
<div>= Alpine Source Map by boot sequence =<br />
<br />
{{Draft|Alternate message.}}<br />
<br />
There are many different running mode/environment for Alpine. Here I try to describe what I've learned by tracing the source code.<br />
<br />
== Boot Sequence ==<br />
<br />
A typical boot sequence of Alpine is:<br />
<br />
# Hardware BIOS<br />
# Boot Loader (syslinux's isolinux)<br />
# Initramfs (linux-grsec)<br />
# Kernel (linux-grsec)<br />
# Init System(openrc)<br />
# Shell(busybox's ash)<br />
<br />
For Embedded System:<br />
<br />
# Boot Loader(UBOOT)<br />
# Kernel<br />
# Init System<br />
# Shell<br />
<br />
For docker:<br />
# Shell<br />
<br />
=== syslinux ===<br />
The 'syslinux.cfg' of {{Pkg|syslinux}} in put in https://github.com/alpinelinux/alpine-iso/blob/master/Makefile<br />
<br />
=== linux-grsec ===<br />
The package kernel into ISO file method in https://github.com/alpinelinux/alpine-iso/blob/master/Makefile.<br />
<br />
The source of kernel in {{Pkg|linux-grsec}}<br />
<br />
== Developer Environment ==<br />
<br />
=== Trace code in docker ===<br />
In any modern Linux distribution, run docker will let you get the same developer environment.<br />
docker run -it --name alpine alpine /bin/sh<br />
<br />
<br />
Create the build/development inside docker<br />
apk update<br />
apk add tmux vim diffutils # my tools<br />
apk add alpine-sdk xorriso syslinux<br />
adduser YOUR_ID # There are some build scripts can't work under 'root' account.<br />
su - YOUR_ID<br />
abuild-keygen -i -a<br />
<br />
Build one package sample(eg. openrc)<br />
git clone https://github.com/alpinelinux/aports<br />
cd aports/main/openrc # change this line to the package which you want to change<br />
abuild -r<br />
ls -l ~/packages/x86_64/openrc*<br />
<br />
When you shut down your PC, you can recall the docker 'alpine' container by<br />
docker start alpine<br />
docker attach alpine<br />
<br />
<br />
=== Test ===<br />
* Test ISO file<br />
qemu-system-x86_64 -enable-kvm -localtime -m 512M -vga std \<br />
-drive file=YOUR_ISO_FILE ,cache=none,if=virtio<br />
<br />
* Test Package in docker<br />
To make sure you got the same environment of default package environment, just use docker.<br />
docker run --it --rm --name alpine-test alpine /bin/sh<br />
apk update<br />
<br />
# on other window copy your new apk into the 'alpine-test' container<br />
docker cp foo.apk alpine-test:/tmp<br />
<br />
# back to 'alpine-test' container<br />
apk fix /tmp/foo.apk<br />
<br />
[[Category:Development]]</div>Dlinhttps://wiki.alpinelinux.org/w/index.php?title=Developer_Documentation&diff=13065Developer Documentation2016-11-29T02:02:44Z<p>Dlin: /* Misc */ Create a source map to help developer finding where to modify</p>
<hr />
<div>[[Image:package_system.svg|right|link=]]<br />
<br />
== Package management ==<br />
<!-- If you edit the following, please coordinate with Tutorials_and_Howtos#Post-Install and Installation#Post-Install. Note that these three sections are not exact duplicates. --><br />
* [[Alpine Linux package management|Package Management (apk)]] ''(How to add/remove packages on your Alpine)'' <!-- <br />
[[Alpine Linux package management#Local_Cache|How to enable APK caching]] --> <!-- includes [[Local APK cache]] --><br />
** [[Comparison with other distros]]<br />
** [[apk spec]]<br />
* [[Edge|Upgrading to Edge]]<br />
* [[Alpine local backup|Alpine local backup (lbu)]] ''(Permanently store your modifications in case your box needs reboot)''<br />
** [[Back Up a Flash Memory Installation]]<br />
** [[Manually editing a existing apkovl]]<br />
<!-- [[Replacing a package]] Obsolete? --><br />
* [[How to setup a Alpine Linux mirror]]<br />
* [[How to use xdelta and download only differential update files]]<br />
* [[How to make a custom ISO image]]<br />
** [[Burning ISOs]]<br />
<br />
== Init system ==<br />
* [[Alpine Linux Init System|Init System (OpenRC)]] ''(Configure a service to automatically launch at next reboot)''<br />
** [[Multiple Instances of Services]]<br />
* [[Writing Init Scripts]]<br />
<br />
== Development ==<br />
=== Configuring your system ===<br />
* [[Edge|Upgrading to Edge]] <!-- Pkg and Dev and Installation --><br />
<br />
<!-- If you edit the following, please coordinate with Installation#Advanced. Note that these two sections are not exact duplicates. --><br />
* [[Setting up the build environment on HDD]] <!-- Dev and Installation --><br />
<!-- [[Setting up the build environment 1.7]] Obsolete, only Dev --><br />
** [[Creating_an_Alpine_package#Setup_your_system_and_account|Setup your system and account for building packages]]<br />
** [[Abuild_and_Helpers#abuild-keygen|Abuild-keygen]]<br />
<br />
* [[Installing Alpine Linux in a chroot]] <!-- only Installation --><br />
** [[Buildlab]] ''(Tool for creating and managing chroots)''<br />
* [[Install Alpine on LXC]]<br />
* Install Alpine on [[Install Alpine on VirtualBox|VirtualBox]], [[Install Alpine on VMware|VMware]], [[Install Alpine on coLinux|coLinux]], [[Qemu]], <!-- includes [[Install Alpine in Qemu]], [[Running Alpine in Qemu Live mode]], [[Running Alpine Linux As a QEMU networked Guest]] --> or [[Install Alpine on Amazon EC2|Amazon EC2]]<br />
<br />
* [[Xen Dom0]] ''(Setting up Alpine as a dom0 for Xen hypervisor)''<br />
** [[Xen Dom0 on USB or SD]]<br />
** [[Create Alpine Linux PV DomU]]<br />
** [[Xen LiveCD]]<br />
<br />
* [[Setting up a basic vserver]] <!-- only Installation --><br />
* [[Setting up a compile vserver]] for official or for [[Setting up a compile vserver for third party packages|third party]] packages <!-- Dev and Installation --><br />
<!-- [[Create an Alpine 1.9 vserver template]] --><br />
<br />
=== Building from source and creating packages ===<br />
<br />
* [[Aports tree]] <!-- <== APKBUILD --><br />
* [[Abuild and Helpers]] ''(Scripts for packaging)''<br />
<!-- includes [[Abuild_and_Helpers#apkbuild-cpan|Apkbuild-cpan]] --><br />
<!-- includes [[Abuild_and_Helpers#apkbuild-pypi|Apkbuild-pypi]] --><br />
<!--<br />
[[Abuild_and_Helpers#buildrepo|Buildrepo]]<br />
[[Abuild_and_Helpers#abuild-sign|Abuild-sign]]<br />
[[Abuild_and_Helpers#abuild-tar|Abuild-tar]]<br />
[[Abuild_and_Helpers#abump|Abump]]<br />
[[Abuild_helpers#apkgrel|Apkgrel]]<br />
--><br />
* [[Creating an Alpine package]]<br />
<!-- includes [[Setup your system and account for building packages]] --><br />
<!-- includes [[Newapkbuild]]<br />
To create the actual APKBUILD file, newapkbuild can give you a template to start with.<br />
It will create a directory with the given package name, place an example/template APKBUILD <br />
file to the given directory, and fill some variables if those are provided. --><br />
<!-- includes [[Local_APK_cache]] --><br />
** [[Package policies]]<br />
** [[Package Maintainers]]<br />
* [[Custom Kernel]]<br />
* [[APKBUILD Reference]]<br />
* [[APKBUILD examples]]<br />
* [[Alpine package format]]<br />
* [[Apkindex format]]<br />
<br />
<br />
* [[Development using git]] <!-- includes [[Development using git:Configuration]] [[Development using git:Email]] --><br />
** [[Development using git:Basic usage|Basic usage]]<br />
** [[Package Maintainers]]<br />
** [[Creating patches]]<br />
** [[Development using git:Developer repositories|Developer repositories]]<br />
** [[Development using git:Cgit|Cgit]]<br />
** [[Cgit|Another cgit page]]<br />
<br />
=== Misc ===<br />
<br />
* [[Alpine Package Testing Suite]] ''work in progress''<br />
* [[Alpine Release Testing Checklist]]<br />
* [[Running glibc programs]]<br />
* [[Alpine Source Map by boot sequence]]<br />
<br />
== Alpine Configuration Framework ==<br />
{{Draft|Needs to be organized/consolidated.}}<br />
<br />
* [[Alpine Configuration Framework Design]] (Why ACF is the way it is)<br />
* [[Writing User Documentation for ACF]]<br />
* [[ACF mvc.lua reference|mvc.lua reference]] - mvc.lua is the core of ACF <br />
* [[ACF mvc.lua example|mvc.lua example]] - build a simple (command-line) application <br />
* [[ACF acf www-controller.lua reference|acf www-controller reference]] - ACF www application functions <br />
* [[ACF acf www example|acf www-controller example]] - webify the above examples <br />
* [[ACF how to write]] - Step by step howto for writing acfs <br />
* [[ACF core principles]] - Things that are standard across the application <br />
* [[LuaPosix]] - Documentation for the Lua Posix functions <br />
* [[ACF Libraries]] - Document the libraries and common functions <br />
* [[Writing ACF Views]] - Guide for writing a view <br />
* [[Writing ACF Controllers]] - Guide for writing a controller <br />
* [[Writing ACF Models]] - Guide for writing a model<br />
<br />
* [[ACF css]]<br />
* [[ACF packages]]<br />
* [[APKBUILD examples:ACF]]<br />
* [[Apk.lua]]<br />
* [[Changing passwords for ACF]]<br />
* [[Generating SSL certs with ACF]]<br />
* [[Generating SSL certs with ACF 1.9]]<br />
* [[Getting started with ACF development]]<br />
* [[Managing ACF]]<br />
<br />
<br />
== Alpine-developed Utilities ==<br />
* [[Alpine Wall]] - [[How-To Alpine Wall]] - [[Alpine Wall User's Guide]] ''(a new firewall management framework)''<br />
<br />
<br />
[[Category:Development]]</div>Dlinhttps://wiki.alpinelinux.org/w/index.php?title=Comparison_with_other_distros&diff=13061Comparison with other distros2016-11-27T09:29:56Z<p>Dlin: /* Directories and files */</p>
<hr />
<div>Even if Alpine is designed to run from ram, it has some similarities in package management with both Gentoo and Debian. This page is supposed to show those differences and help Debian and Gentoo users to use Alpine.<br />
<br />
The page was originally copied from: http://gentoo-wiki.com/TIP_Converting_from_or_to_Debian<br />
<br />
=Package management=<br />
Where Gentoo has portage and emerge and Debian has, among others, apt, Alpine uses apk-tools. This compares how you use apk-tools in comparation to apt-get/aptitude and emerge.<br />
<br />
Note that Gentoo is source based, just like ports in FreeBSD is while Debian uses pre-compiled binaries. Alpine is compiled using Gentoo portage but Alpine itself uses its own apk-tools binary package that are more similar FreeBSD's binary packages.<br />
<br />
==Updating package database==<br />
Gentoo will update the build-from-source scripts and are the updating of the database is takes much more time that updating the database for Debian or Alpine.<br />
<br />
'''Alpine'''<br />
apk update<br />
<br />
'''Gentoo'''<br />
emerge --sync<br />
<br />
'''Debian'''<br />
aptitude update<br />
<br />
==Showing available updates==<br />
Show what packages that have an update available:<br />
<br />
'''Alpine'''<br />
apk version -v<br />
or:<br />
apk version -v -l '<'<br />
<br />
'''Gentoo'''<br />
emerge --deep --update --pretend world<br />
<br />
'''Debian'''<br />
aptitude upgrade --simulate<br />
<br />
==Update a particular package==<br />
'''Alpine'''<br />
apk add -u package1 package2<br />
'''Debian'''<br />
aptitude install package1 package2<br />
'''Gentoo'''<br />
emerge --update package1 package2<br />
<br />
==Installing packages==<br />
'''Alpine'''<br />
apk add package1 package2<br />
For source compile,<br />
see the [[Aports tree]] and the [[abuild]] tool<br />
<br />
'''Gentoo'''<br />
emerge package1 package2<br />
'''Debian'''<br />
apt-get install package1 package2<br />
Debian source compile:<br />
apt-get build-dep package1<br />
apt-get source package1<br />
(optional: customize the build by modifying the debian/rules makefile)<br />
(or set environmental variables like DEB_BUILD_OPTIONS)<br />
(note that this will make your bug reports invalid to the maintainer)<br />
dpkg-buildpackage -rfakeroot -uc -b<br />
dpkg -i generatedpackagename<br />
Simplified source compile:<br />
apt-get build-dep package1<br />
apt-get -b source package1<br />
(the packages are automatically generated using the -b switch above)<br />
<br />
'''Note:''' This process can be used to backport packages from testing and unstable by simply adding their respective source repositories to sources.list, which is similar to adding ~x86 to package.keywords in Gentoo. This is explored further in "arch and repositories" below.<br />
<br />
== Reinstall a particular package ==<br />
'''Alpine'''<br />
apk del package1 && apk add package1<br />
or:<br />
apk_add -f package1 package1<br />
'''Gentoo'''<br />
emerge --oneshot package1<br />
'''Debian'''<br />
apt-get install --reinstall package1 package1<br />
<br />
Note: You ''rarely'' need to reinstall a package on Debian<br />
<br />
==Searching package database==<br />
'''Alpine'''<br />
<br />
Alpine will only search package names.<br />
apk search searchword<br />
<br />
'''Gentoo'''<br />
<br />
To search the package names and descriptions:<br />
emerge --searchdesc searchword<br />
'''Note:''' On Gentoo, it's actually much better to install and use either the esearch package or the eix package to do a search. You use them like this:<br />
eix searchword<br />
<br />
or<br />
<br />
esearch searchword<br />
<br />
'''Debian'''<br />
<br />
apt-cache search searchword<br />
Both emerge and apt-cache search support regular expressions.<br />
<br />
To get the long package information on Debian (searching only in package names):<br />
apt-cache search --full --names-only searchword<br />
<br />
==Removing packages==<br />
'''Alpine'''<br />
<br />
apk del package1 package2<br />
apk del will remove configuration files when the --purge flag is used. Make sure you have backups of your configuration files. (Using rcs might be an idea)<br />
<br />
You will mostly like to take a quick look at the dependencies before you remove packages recursively.<br />
<br />
To see dependencies for a package, use:<br />
apk info -R package1 package2<br />
<br />
To see if package is required by other packages (is a dependency for another packages), use:<br />
apk info -r package1 package2<br />
<br />
<br />
'''Gentoo'''<br />
emerge --unmerge package1 package2 (Note: this is unsafe as it does not check dependencies)<br />
emerge --depclean package1 package2 (This will check dependencies)<br />
<br />
'''Debian'''<br />
apt-get remove package1 package2<br />
or to remove along with all configuration files<br />
apt-get remove --purge package1 package2<br />
<br />
==Only downloading packages==<br />
This can be useful e.g. if you're on a dial-up connection and want to download everything first and install later.<br />
<br />
'''Alpine'''<br />
apk fetch package1 package2<br />
'''Gentoo'''<br />
emerge --fetchonly package1 package2<br />
'''Debian'''<br />
apt-get install --download-only package1 package2<br />
<br />
==Cleaning up downloaded packages==<br />
Compressed packages that were downloaded for installation can easily consume gigs of hdd space.<br />
<br />
'''Alpine'''<br />
<br />
Alpine will clean up packages automatically.<br />
<br />
'''Gentoo'''<br />
rm -rf /usr/portage/distfiles/*<br />
To only remove outdated packages you will need to install the gentoolkit package and use eclean:<br />
eclean distfiles<br />
Cleaning temporary files from emerging packages:<br />
rm -rf /var/tmp/portage/*<br />
<br />
'''Debian'''<br />
apt-get clean<br />
Only remove outdated packages:<br />
apt-get autoclean<br />
<br />
==Reverse dependencies==<br />
<br />
'''Alpine'''<br />
<br />
apk-tools will take care of reverse dependencies.<br />
<br />
'''Gentoo'''<br />
<br />
Reverse dependencies are a major drawback of '''Gentoo's''' current portage implementation: It does not take care of them at all at the moment.<br />
If you use the unsafe --unmerge argument, this means that you can uninstall packages needed by others without being warned about it. E.g. you can remove the x server package without portage warning you that kde (which you have installed as well) depends on it. This way you can actually break your entire system (e.g. by removing glibc).<br />
<br />
revdep-rebuild<br />
can fix broken dependencies broken by<br />
emerge --depclean<br />
<br />
Recent versions of portage include library tracking and preservation with the preserved-libs feature. Portage will notify you to run {{Cmd| emerge @preserved-rebuild}} to help rebuild binaries that might otherwise become broken.<br />
<br />
'''Debian'''<br />
<br />
Reverse dependencies are taken care of by dpkg.<br />
<br />
=Runlevel & Initscripts=<br />
Runlevels work pretty conventionally on Debian. On Alpine and Gentoo, they are a bit different.<br />
==Directories and files==<br />
In '''Debian''' runlevels are named conventionally (0-6 and S). They are represented by directories in /etc/ called rc*.d (when the default sysv-rc boot loader package is installed; file-rc can be installed instead, and then the relevant file is runlevel.conf).<br />
* /etc/rc0.d<br />
* /etc/rc1.d<br />
* /etc/rcS.d<br />
* /etc/rc2.d<br />
* /etc/rc3.d<br />
* /etc/rc4.d<br />
* /etc/rc5.d<br />
* /etc/rc6.d<br />
<br />
In '''Gentoo''', runlevels have the same names, but these are mapped to more self explanatory ones (in /etc/inittab): "boot", "default", "nonetwork", with the option to add more. The directories that represent them are in <br />
/etc/runlevels/:<br />
* /etc/runlevels/boot<br />
* /etc/runlevels/default<br />
* /etc/runlevels/nonetwork<br />
<br />
In Gentoo, if a service is not explicitly started in a runlevel, it is stopped when switching to that runlevel! There is no explicit stopping of runlevels as in Debian (/etc/rc?.d/K??service).<br />
<br />
In '''both Debian and Gentoo''', which things are started (and stopped) in which runlevels is controlled by links in the runlevel directories to scripts in /etc/init.d/, e.g.:<br />
gentoo <br />
$ ls -l /etc/runlevels/boot/hostname<br />
lrwxrwxrwx 1 root root 20 Mar 25 2004 /etc/runlevels/boot/hostname -> /etc/init.d/hostname<br />
<br />
'''Debian'''<br />
$ ls -l rcS.d/S40hostname.sh<br />
lrwxrwxrwx 1 root root 21 2004-11-07 00:19 rcS.d/S40hostname.sh -> ../init.d/hostname.sh<br />
<br />
'''Alpine'''<br />
In '''Alpine''', runlevels works like Gentoo:<br />
<br />
* /etc/runlevels/boot<br />
* /etc/runlevels/default<br />
* /etc/runlevels/sysinit<br />
* /etc/runlevels/nonetwork<br />
* /etc/runlevels/shutdown<br />
<br />
==Runlevel management==<br />
To manage which things to start in which runlevels, use the following commands:<br />
<br />
'''Alpine'''<br />
<br />
To see current status of services in runlevels, do:<br />
rc-status<br />
To add sshd to default runlevel, do:<br />
rc-update add -k sshd default<br />
The -k option will make sure sshd is stopped when shutting down or reboot.<br />
To remove sshd from all runlevels do:<br />
rc-update del sshd<br />
<br />
'''Gentoo'''<br />
<br />
rc-update<br />
To add the cupsd to the default runlevel, do:<br />
rc-update add cupsd default<br />
To remove alsasound from the boot runlevel, do:<br />
rc-update del alsasound boot<br />
Also see this wiki page about [http://gentoo-wiki.com/Rc-update gentoo runlevel management with rc-update]<br />
<br />
'''Debian'''<br />
<br />
update-rc.d<br />
Configure cupsd to be started in runlevels 2, 3, 4, 5, and stopped in 0, 1, 6, with sequence code 20:<br />
update-rc.d cupsd start 20 2 3 4 5 . stop 20 0 1 6 . <br />
or simply:<br />
update-rc.d cupsd defaults <br />
Remove cupsd from all runlevels:<br />
update-rc.d -f cupsd remove<br />
<br />
=Config Files=<br />
<br />
==/etc/portage/make.conf and use flags==<br />
While in gentoo there are a large number of configuration files which exist to control the behaviour of the package management system. There are comparatively fewer in Debian, as there is no need to dictate how to compile software which is downloaded and tweak / alter this purpose. In gentoo, the file /etc/portage/make.conf is used for much configuration; this includes ''USE'' flags, which influence which elements of packages are compiled, and which libraries to build support for - common USE flags (USE or -USE to specifically negate support) include 'gtk gnome' for gnome users (and a corresponding -qt -kde -arts) and 'qt kde arts' for kde users. A gentoo user's complete set of use flags may look something like this:<br />
<br />
'''USE="-kde -arts -qt xv truetype bluetooth crypt slang readline gpm berkdb mmx gdbm tcpd pam libwww ssl nls ethereal perl python esd gif imlib sdl oggvorbis mpeg gnome gtk X motif opengl avi png tiff nptl pcmcia nptl ldap eds"'''<br />
<br />
==arch and repositories==<br />
'''Gentoo'''<br />
<br />
Also in /etc/portage/make.conf is the '''ACCEPT_KEYWORDS''' setting, with (for an X86-based processor) two settings, '''x86''' for stabler packages, and '''~x86''' for bleeding edge packages. It is however not recommended to make this change in /etc/portage/make.conf. Rather configure this per-package in /etc/portage/package.accept_keywords. It's enough to put a line into that file naming the package (for example 'app-foo/bar'). That file might look like this:<br />
<br />
app-crypt/gpg-agent<br />
app-text/docbook-xsl-stylesheets<br />
=app-text/docbook-xml-dtd-4.3-r1<br />
<br />
The last line says, that ''only'' version 4.3-r1 should be unmasked. Older and newer versions will still be ignored.<br />
<br />
'''Note for non-x86 users:'''<br />
The keywords '''x86''' and '''~x86''' can of course be replaced by '''sparc''' and '''~sparc''' for example.<br />
<br />
'''Debian'''<br />
<br />
Setting this in Debian is slightly more complicated, and is accomplished by setting different 'repositories' in ''/etc/apt/sources.list'' - along with which 'tree' to use for packages; in debian, these are '''stable''', '''testing''', and '''unstable'''. An ''/etc/apt/sources.list'' file for a debian testing user may look something like this:<br />
<br />
deb http://mirrors.kernel.org/debian testing main non-free contrib<br />
deb ftp://ftp.nerim.net/debian-marillat testing main<br />
deb http://security.debian.org testing/updates main contrib non-free<br />
<br />
Alternatively, ''/etc/apt/sources.list'' can contain any number of repositories for any trees, and a default tree (this can be overridden using the -t switch on the command line) in ''/etc/apt/apt.conf'':<br />
<br />
APT::Default-Release "testing";<br />
<br />
Per-package settings go in ''/etc/apt/preferences'', somewhat like Gentoo's ''/etc/portage/package.keywords''.<br />
<br />
==Network==<br />
<br />
'''Alpine'''<br />
<br />
Alpine uses /etc/network/interfaces, just like Debian. The main reason is because this is the way busybox does it.<br />
<br />
''/etc/network/interfaces'':<br />
auto eth0<br />
iface eth0 inet static<br />
address 192.168.0.1<br />
netmask 255.255.255.0<br />
broadcast 192.168.0.255<br />
<br />
auto eth0:0<br />
iface eth0:0 inet static<br />
address 192.168.1.1<br />
netmask 255.255.255.0<br />
broadcast 192.168.1.255<br />
# etc.<br />
<br />
'''Gentoo'''<br />
<br />
''/etc/conf.d/net'':<br />
config_eth0="192.168.1.100 netmask 255.255.255.0<br />
192.168.2.100 netmask 255.255.255.0"<br />
routes_eth0="default via 192.168.1.1"<br />
<br />
Note that this has changed recently. For more information please refer to http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=4<br />
<br />
'''Debian'''<br />
<br />
''/etc/network/interfaces'':<br />
auto eth0<br />
iface eth0 inet static<br />
address 192.168.0.1<br />
netmask 255.255.255.0<br />
broadcast 192.168.0.255<br />
<br />
auto eth0:0<br />
iface eth0:0 inet static<br />
address 192.168.1.1<br />
netmask 255.255.255.0<br />
broadcast 192.168.1.255<br />
# etc.<br />
<br />
= Comparison chart =<br />
<br />
This chart shows how some standard things are done in Alpine compared to other distributions.<br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|-<br />
! Action <br />
! Alpine ([http://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management apk])<br />
! Arch Linux ([https://wiki.archlinux.org/index.php/Pacman pacman])<br />
! Gentoo ([http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1 emerge])<br />
! Debian/Ubuntu ([http://wiki.debian.org/Aptitude aptitute])<br />
! Fedora/RHEL/SL/Centos ([http://yum.baseurl.org/wiki/YumCommands yum])<br />
|-<br />
| Update package database<br />
| {{Cmd| apk update}}<br />
| {{Cmd| pacman -Sy}}<br />
| {{Cmd| emerge --sync}}<br />
| {{Cmd| aptitude update}}<br />
| {{Cmd| yum update}}<br />
|-<br />
| Showing available updates<br />
| {{Cmd| apk version -l '<'}}<br />
| <br />
| {{Cmd| emerge --deep --update --pretend @world}}<br />
| {{Cmd| aptitude upgrade --simulate}}<br />
| {{Cmd| yum list updates}}<br />
|-<br />
| Installing packages<br />
| {{Cmd| apk add [package name]}}<br />
| {{Cmd| pacman -S [package name]}}<br />
| {{Cmd| emerge [package name]}}<br />
| {{Cmd| aptitude install [package name]}}<br />
| {{Cmd| yum install [package name]}}<br />
|-<br />
| Update all installed packages<br />
| {{Cmd| apk upgrade -U -a}}<br />
| {{Cmd| pacman -S [package name]}}<br />
| {{Cmd| emerge --update --deep @world}}<br />
| {{Cmd| aptitude update}}<br />
| {{Cmd| yum update}}<br />
|- <br />
| Searching package database<br />
| {{Cmd| apk search -v '[string]*'}}<br />
| {{Cmd| pacman -Ss [string]}}<br />
| {{Cmd| emerge --search [string]}}<br />
| {{Cmd| aptitude search [string]}}<br />
| {{Cmd| yum search [string]}}<br />
|-<br />
| Removing packages<br />
| {{Cmd| apk del [package name]}}<br />
| {{Cmd| pacman -R [package name]}}<br />
| {{Cmd| emerge --depclean [package name]}}<br />
| {{Cmd| aptitude remove [package name]}}<br />
| {{Cmd| yum remove [package name]}}<br />
|}<br />
<br />
[[Category:Package Manager]]</div>Dlinhttps://wiki.alpinelinux.org/w/index.php?title=How_to_make_a_custom_ISO_image&diff=13060How to make a custom ISO image2016-11-27T04:44:15Z<p>Dlin: /* Package lists */ format</p>
<hr />
<div>This document explains how to build a custom ISO image using the alpine-iso scripts.<br />
<br />
== Prerequisite ==<br />
<br />
First make sure we have the needed tools<br />
{{Cmd|apk add alpine-sdk xorriso syslinux}}<br />
<br />
Then create signing keys (-i installs them in /etc/apk/keys which is required for later)<br />
{{Cmd|abuild-keygen -i}}<br />
<br />
Clone (or update) the [http://git.alpinelinux.org/cgit/alpine-iso.git/ alpine-iso git repository].<br />
{{Cmd|git clone git://git.alpinelinux.org/alpine-iso}}<br />
<br />
== Core Configuration ==<br />
<br />
The alpine-iso scripts is a simple makefile which you need to feed with a ''<name>.conf.mk'' file and a ''<name>.packages''. <br />
<br />
In the ''<name>.conf.mk'' we specify<br />
<br />
;ALPINE_NAME<br />
:name of iso image<br />
<br />
;ALPINE_VERSION<br />
:(optional) version string. Will default to todays date.<br />
<br />
;KERNEL_FLAVOR<br />
:(optional) either ''grsec'', ''vserver'' or ''pae''. Will default to grsec.<br />
<br />
;MODLOOP_EXTRA<br />
:(optional) Extra kernel module packages for the modloop image. For example: ''dahdi-linux-vserver''<br />
<br />
;APK_REPOS<br />
:(optional) Path to addidtional apk repository.<br />
<br />
The ''<name>.packages'' is just a plaintext list of packages that should be included in the ISO image. You should always add ''alpine-base'' in there or the CD might not be able to boot. The dependencies for the packages will automatically be pulled in.<br />
<br />
== A rescue CD example ==<br />
As an example, let us make a rescue ISO image with packages needed for rescue operations. We call it ''alpine-rescue''<br />
<br />
We create the ''alpine-rescue.conf.mk'' as follows:<br />
ALPINE_NAME := alpine-rescue<br />
KERNEL_FLAVOR := grsec<br />
MODLOOP_EXTRA :=<br />
<br />
If you are going to use a custom kernel, don't forget to specify KERNEL_FLAVOR_DEFAULT which will set the default kernel to boot.<br />
<br />
And then the ''alpine-rescue.packages'' as:<br />
alpine-base<br />
bkeymaps<br />
openssh<br />
e2fsprogs<br />
mdadm<br />
lvm2<br />
parted<br />
debootstrap<br />
ntfs-3g<br />
<br />
{{Tip| Make sure your public keys are placed in /etc/apk/keys/ (example: root-xxxxxxxx.rsa.pub):<br />
{{Cmd|ls /etc/apk/keys/}}<br />
<br />
Learn apk-tools to find your home-built apk's:<br />
{{Cmd|echo "~/.cache/abuild/" >> /etc/apk/repositories}}<br />
}}<br />
<br />
Make sure the apk index is up to date (so apk finds the packages):<br />
{{Cmd|apk update}}<br />
<br />
We create the ISO image by telling the makefile the profile name. The makefile target is ''iso''.<br />
{{Cmd|<nowiki>make PROFILE=alpine-rescue iso</nowiki>}}<br />
<br />
{{Tip| If you are building inside an LXC guest, use fakeroot:<br />
{{Cmd|<nowiki>fakeroot make PROFILE=alpine-rescue iso</nowiki>}}<br />
}}<br />
<br />
To generate the sha1 sum we use the ''sha1'' make target.<br />
{{Cmd|<nowiki>make PROFILE=alpine-rescue sha1</nowiki>}}<br />
<br />
== Package lists ==<br />
<br />
Beside the plaintext package lists in the git repository, there are more documented package lists contributed by Alpine users. Those lists can be transformed into a plain text description by <code>apk search --exact -v $(cat alpine.packages)</code>.<br />
<br />
So far the lists below are available (check [[:Category:ISO|here]] for more.)<br />
<br />
* [[Alpine_mini|Alpine Mini]]<br />
* [[Alpine_rescue|Alpine Rescue]]<br />
* [[Alpine_security|Alpine Security]]<br />
* [[Alpine SCST]]<br />
<br />
== Live Disk Setup with APKOVL ==<br />
<br />
Once you have customized your custom ISO, you can now setup the live environment to operate outside of the standard installer as follows:<br />
<br />
* Generate an APKOVL file with [[Alpine_local_backup|lbu]], <code>lbu ci</code><br />
* Alpine ISO requires the OVL Volume to be hosted on a web server. Put the APKOVL file on a webserver and identify the url. <br />
* Uncomment the <code>APKOVL</code> line in the alpine flavor of your choice and set it to the address of your ovl volume.<br />
<br />
Notes:<br />
<br />
* Any packages you add to /etc/apk/world of your lbu will automatically be installed onto the live system image.<br />
* If you don't have a web server you can run busybox's httpd temporarily - <code>busybox -p 127.0.0.1:80</code><br />
* In general, <code>lbu</code> will only handle files in <code>/etc</code>, to customize this further, you need to add additional files.<br />
* If you want to make a customized installer, you need to create <code>.default_boot_services</code> which will cause <code>mkinitfs</code> to create the defaults for the live image.<br />
<br />
== Testing your ISO image ==<br />
<br />
[[Qemu#Live_mode| Qemu]] is useful for a quick test of your created ISO image.<br />
<br />
[[Category:Package Manager]]<br />
[[Category:ISO]]</div>Dlinhttps://wiki.alpinelinux.org/w/index.php?title=How_to_make_a_custom_ISO_image&diff=13059How to make a custom ISO image2016-11-27T04:43:30Z<p>Dlin: /* Package lists */ added command for get package description</p>
<hr />
<div>This document explains how to build a custom ISO image using the alpine-iso scripts.<br />
<br />
== Prerequisite ==<br />
<br />
First make sure we have the needed tools<br />
{{Cmd|apk add alpine-sdk xorriso syslinux}}<br />
<br />
Then create signing keys (-i installs them in /etc/apk/keys which is required for later)<br />
{{Cmd|abuild-keygen -i}}<br />
<br />
Clone (or update) the [http://git.alpinelinux.org/cgit/alpine-iso.git/ alpine-iso git repository].<br />
{{Cmd|git clone git://git.alpinelinux.org/alpine-iso}}<br />
<br />
== Core Configuration ==<br />
<br />
The alpine-iso scripts is a simple makefile which you need to feed with a ''<name>.conf.mk'' file and a ''<name>.packages''. <br />
<br />
In the ''<name>.conf.mk'' we specify<br />
<br />
;ALPINE_NAME<br />
:name of iso image<br />
<br />
;ALPINE_VERSION<br />
:(optional) version string. Will default to todays date.<br />
<br />
;KERNEL_FLAVOR<br />
:(optional) either ''grsec'', ''vserver'' or ''pae''. Will default to grsec.<br />
<br />
;MODLOOP_EXTRA<br />
:(optional) Extra kernel module packages for the modloop image. For example: ''dahdi-linux-vserver''<br />
<br />
;APK_REPOS<br />
:(optional) Path to addidtional apk repository.<br />
<br />
The ''<name>.packages'' is just a plaintext list of packages that should be included in the ISO image. You should always add ''alpine-base'' in there or the CD might not be able to boot. The dependencies for the packages will automatically be pulled in.<br />
<br />
== A rescue CD example ==<br />
As an example, let us make a rescue ISO image with packages needed for rescue operations. We call it ''alpine-rescue''<br />
<br />
We create the ''alpine-rescue.conf.mk'' as follows:<br />
ALPINE_NAME := alpine-rescue<br />
KERNEL_FLAVOR := grsec<br />
MODLOOP_EXTRA :=<br />
<br />
If you are going to use a custom kernel, don't forget to specify KERNEL_FLAVOR_DEFAULT which will set the default kernel to boot.<br />
<br />
And then the ''alpine-rescue.packages'' as:<br />
alpine-base<br />
bkeymaps<br />
openssh<br />
e2fsprogs<br />
mdadm<br />
lvm2<br />
parted<br />
debootstrap<br />
ntfs-3g<br />
<br />
{{Tip| Make sure your public keys are placed in /etc/apk/keys/ (example: root-xxxxxxxx.rsa.pub):<br />
{{Cmd|ls /etc/apk/keys/}}<br />
<br />
Learn apk-tools to find your home-built apk's:<br />
{{Cmd|echo "~/.cache/abuild/" >> /etc/apk/repositories}}<br />
}}<br />
<br />
Make sure the apk index is up to date (so apk finds the packages):<br />
{{Cmd|apk update}}<br />
<br />
We create the ISO image by telling the makefile the profile name. The makefile target is ''iso''.<br />
{{Cmd|<nowiki>make PROFILE=alpine-rescue iso</nowiki>}}<br />
<br />
{{Tip| If you are building inside an LXC guest, use fakeroot:<br />
{{Cmd|<nowiki>fakeroot make PROFILE=alpine-rescue iso</nowiki>}}<br />
}}<br />
<br />
To generate the sha1 sum we use the ''sha1'' make target.<br />
{{Cmd|<nowiki>make PROFILE=alpine-rescue sha1</nowiki>}}<br />
<br />
== Package lists ==<br />
<br />
Beside the plaintext package lists in the git repository, there are more documented package lists contributed by Alpine users. Those lists can be transformed into a plain text description by <tt>apk search --exact -v $(cat alpine.packages)</tt>.<br />
<br />
So far the lists below are available (check [[:Category:ISO|here]] for more.)<br />
<br />
* [[Alpine_mini|Alpine Mini]]<br />
* [[Alpine_rescue|Alpine Rescue]]<br />
* [[Alpine_security|Alpine Security]]<br />
* [[Alpine SCST]]<br />
<br />
== Live Disk Setup with APKOVL ==<br />
<br />
Once you have customized your custom ISO, you can now setup the live environment to operate outside of the standard installer as follows:<br />
<br />
* Generate an APKOVL file with [[Alpine_local_backup|lbu]], <code>lbu ci</code><br />
* Alpine ISO requires the OVL Volume to be hosted on a web server. Put the APKOVL file on a webserver and identify the url. <br />
* Uncomment the <code>APKOVL</code> line in the alpine flavor of your choice and set it to the address of your ovl volume.<br />
<br />
Notes:<br />
<br />
* Any packages you add to /etc/apk/world of your lbu will automatically be installed onto the live system image.<br />
* If you don't have a web server you can run busybox's httpd temporarily - <code>busybox -p 127.0.0.1:80</code><br />
* In general, <code>lbu</code> will only handle files in <code>/etc</code>, to customize this further, you need to add additional files.<br />
* If you want to make a customized installer, you need to create <code>.default_boot_services</code> which will cause <code>mkinitfs</code> to create the defaults for the live image.<br />
<br />
== Testing your ISO image ==<br />
<br />
[[Qemu#Live_mode| Qemu]] is useful for a quick test of your created ISO image.<br />
<br />
[[Category:Package Manager]]<br />
[[Category:ISO]]</div>Dlinhttps://wiki.alpinelinux.org/w/index.php?title=Talk:Uvesafb&diff=12679Talk:Uvesafb2016-04-17T01:49:10Z<p>Dlin: Created page with "This method could not work, I'm using diskless mode Alpine. After reboot, it failed to mount loop"</p>
<hr />
<div>This method could not work, I'm using diskless mode Alpine. After reboot, it failed to mount loop</div>Dlinhttps://wiki.alpinelinux.org/w/index.php?title=Include:Setup_your_system_and_account_for_building_packages&diff=12667Include:Setup your system and account for building packages2016-04-11T16:06:02Z<p>Dlin: The abuild group is required</p>
<hr />
<div>The {{Pkg|alpine-sdk}} is a metapackage that pulls in the most essential packages used to build new packages. Install those packages now: <br />
<br />
{{Cmd|apk add alpine-sdk}}<br />
<br />
This would be a good time to create a normal user account for you to work in. (You weren't going to develop as root now, were you!) To create the user:<br />
<br />
{{Cmd|adduser <yourusername>}}<br />
<br />
To make life easier later, it's a good idea to add this user to {{Path|/etc/sudoers}}. Append the line<br />
<br />
<yourusername> ALL=(ALL) ALL<br />
<br />
using the command:<br />
<br />
{{Cmd|visudo}}<br />
<br />
Now logout of the root account, and login as <yourusername>. From here on everything can be done in a normal user account, and operations that require superuser privileges can be done with sudo.<br />
<br />
The [[Aports_tree|aports tree]] is in git so before we clone the it, let's configure git.<br />
<br />
{{Cmd|git config --global user.name "Your Full Name"<br />
git config --global user.email "your@email.address"}}<br />
<br />
Read carefully [[Development using git]] to grasp basic Git operations and how to configure for sending email patches.<br />
<br />
Now we can clone the [[Aports_tree|aports tree]]. <br />
<br />
{{Cmd|git clone git://dev.alpinelinux.org/aports}}<br />
<br />
Before we start creating or modifying [[APKBUILD_Reference|APKBUILD]] files, we need to setup abuild for our system and user. Edit the file {{Path|abuild.conf}} to your requirements:<br />
<br />
{{Cmd|sudo vi /etc/abuild.conf}}<br />
<br />
Most of the defaults can be left alone, unless you are developing for a custom platform, in which case the comments in the file should guide you. The one field to edit is PACKAGER, so that you can get credit (or blame) for packages you create.<br />
<br />
To use 'abuild -r' command to install dependency packages automatically.<br />
{{Cmd|sudo addgroup <yourusername> abuild}}<br />
<br />
We also need to prepare the location that the build process caches files when they are downloaded. By default this is {{Path|/var/cache/distfiles/}}. To create this directory and ensure that it is writeable, enter the following commands:<br />
<br />
{{Cmd|sudo mkdir -p /var/cache/distfiles<br />
sudo chmod a+w /var/cache/distfiles}}<br />
<br />
As an alternative to the second command, you can add yourself to the abuild group:<br />
<br />
{{Cmd|sudo chgrp abuild /var/cache/distfiles<br />
sudo chmod g+w /var/cache/distfiles}}<br />
<br />
{{Note|Remember to logout and login again for the group change to have effect.}}<br />
<br />
The last step is to configure the security keys with the [[Abuild-keygen|abuild-keygen]] script for [[Abuild|abuild]] with the command:<br />
<br />
{{Cmd|abuild-keygen -a -i}}<br />
<br />
[[Category:Development]]</div>Dlinhttps://wiki.alpinelinux.org/w/index.php?title=Include:Copying_Alpine_to_Flash&diff=12666Include:Copying Alpine to Flash2016-04-11T09:20:37Z<p>Dlin: /* Automated */ added workable step on v3.3</p>
<hr />
<div>=== Boot Alpine Linux CD-ROM ===<br />
# Insert the Alpine Linux CD-ROM into a computer.<br />
# Boot the computer from the Alpine Linux CD-ROM.<br />
#* This step may require changes to the BIOS settings to select booting from CD. <br />
# Login with the username ''root''. No password is needed.<br />
<br />
{{Tip|If you're not able to boot from the CD, then another option is to boot from a regular Alpine installation, and [[Burning_ISOs|manually mount the ISO image to {{Path|/media/cdrom}}]].}} <br />
<br />
=== Determine the Device Name of the {{{1|Flash Medium}}} ===<br />
Determine the name your computer uses for your {{{1|flash medium}}}. The following step is one way to do this.<br />
# After inserting the {{{1|flash medium}}}, run the command:<br />
#* {{Cmd|dmesg}}<br />
#* At the end of this command you should see the name of your {{{1|flash medium}}}, likely starting with "sd". (For example: "sda").<br />
#* The remainder of this document will assume that your {{{1|flash medium}}} is called /dev/sda<br />
# Use "fdisk -l" or "blkid" to check the device name by size or label<br />
<br />
=== Format {{{1|Flash Medium}}} ===<br />
Run fdisk (replacing sda with your {{{1|flash medium}}} name):<br />
{{Cmd|fdisk /dev/sda}}<br />
<br />
# (''Optional'') - Create new partition table with one FAT32 partition<br />
#* '''d''' Delete all partitions (this may take a few steps)<br />
#* '''n''' Create a new partition<br />
#* '''p''' A primary partition<br />
#* '''1''' Partition number 1<br />
#** Use defaults for first and last cylinder (just press [Enter] twice).<br />
#* '''t''' Change partition type<br />
#* '''c''' Partition type (Win95 FAT32/LBA)<br />
#Verify that the primary partition is bootable<br />
#* '''p''' Print list of partitions<br />
#* If there is no '*' next to the first partition, follow the next steps:<br />
#** '''a''' <big>Make the partition bootable (set boot flag)</big><br />
#** '''1''' Partition number 1<br />
#'''w''' Write your changes to the device<br />
<br />
=== Add Alpine Linux to the {{{1|Flash Medium}}} ===<br />
To boot from your {{{1|flash medium}}} you need to copy the contents of the CDROM to the {{{1|flash medium}}} and make it bootable. Those two operations can be automated with the [[setup-bootable]] tool or can be done manually.<br />
<br />
See also notes to [http://it-offshore.co.uk/linux/alpine-linux/48-alpine-linux-usb-stick-kvm create an Alpine Linux USB stick from within KVM] with [[setup-bootable]].<br />
<br />
{{Note|If the following commands fail due to 'No such file or directory', you may have to remove and reinsert the {{{1|flash medium}}}, or even reboot, to get /dev/sda1 to appear}}<br />
<br />
==== Automated ====<br />
{{Tip|If using Alpine Linux 1.10.4 or newer, you can use this section to complete the install. Otherwise, follow the Manual steps below.}}<br />
{{Note|The target partition has to be formatted. Use the <code>mkdosfs</code> command from the Manual steps below if needed.}}<br />
# Run the [[setup-alpine]] script to setup network(Alpine Linux 3.3 not contain syslinux), answer the the last three questions as 'none'<br />
## Which disk(s) would you like to use: none<br />
## Enter where to store configs: none<br />
## Enter where to store configs: none<br />
## Enter apk cache directory: none<br />
# Run "apk add syslinux" to install syslinux package<br />
# Run "modprobe vfat" to load vfat kernel module<br />
# Run the [[setup-bootable]] script to add Alpine Linux to the {{{1|flash medium}}} and make it bootable (replacing sda with your {{{1|flash medium}}} name):<br />
#: {{Cmd|setup-bootable /media/cdrom /dev/sda1}}<br />
## if "Resource busy" occurs, maybe the old files on /media/sda1, "rm /media/sda1/.alpine-release" and "reboot" to try again.<br />
{{Note|If you get something like '<code>Failed to mount /dev/sda1 on /media/sda1</code>' when running the above [[setup-bootable]] command, you might want to try running:<br />
{{Cmd|modprobe vfat}}<br />
and then try re-run the [[setup-bootable]] command as described above.}}<br />
{{Warning|If you are installing to a USB Stick, you may need to modify the {{Path|syslinux.cfg}} file to say <code>usbdisk</code> as [[#Wrong_Device_Name|described below]], or you will face possible problems booting and definite problems with the package cache. Recent versions of <code>setup-bootable</code> will specify the alpine_dev using a UUID instead, so it should work properly by default.}}<br />
<br />
==== Manual ====<br />
# (''Optional'') - If you created a new partition above, format the {{{1|flash medium}}} with a FAT32 filesystem (replacing sda with your {{{1|flash medium}}} name):<br />
#: {{Cmd|apk add dosfstools<BR>mkdosfs -F32 /dev/sda1}}<br />
# Install syslinux and MBR (replacing sda with your {{{1|flash medium}}} name):<br />
#: {{Cmd|{{{|apk add syslinux<BR>dd if=/usr/share/syslinux/mbr.bin of=/dev/sda}}}<BR>syslinux /dev/sda1}}<br />
#Copy the files to the {{{1|flash medium}}} (replacing sda with your {{{1|flash medium}}} name):<br />
#: {{Cmd|<nowiki>mkdir -p /media/sda1<br />
mount -t vfat /dev/sda1 /media/sda1<br />
cd /media/cdrom<br />
cp -a .alpine-release * /media/sda1/<br />
umount /media/sda1</nowiki>}}<br />
# (''Optional'') Remove any apkovl files that were transfered as part of the copy process. This should be done if you wish to have a fresh install. Replace sda with your {{{1|flash medium}}} name)<br />
#: {{Cmd|<nowiki>mount -t vfat /dev/sda1 /media/sda1<br />
rm /media/sda1/*.apkovl.tar.gz<br />
umount /media/sda1</nowiki>}}<br />
<br />
== Troubleshooting ==<br />
=== Wrong Device Name ===<br />
If you cannot boot from the {{{1|flash medium}}} and you see something like:<br />
Mounting boot media failed.<br />
initramfs emergency recovery shell launched. Type 'exit' to continue boot<br />
then it is likely that the device name in {{Path|syslinux.cfg}} is wrong. You should replace the device name in this line:<br />
append initrd=/boot/grsec.gz alpine_dev='''usbdisk''':vfat modules=loop,cramfs,sd-mod,usb-storage quiet<br />
with the proper device name.<br />
* For boot from USB, the device name should be 'usbdisk' (as shown above)<br />
* For other options, you can run <code>cat /proc/partitions</code> to see the available disks (i.e. 'sda' or 'sdb')<br />
<br />
=== Non-FAT32 Filesystems ===<br />
When your {{{1|flash medium}}} is formatted with a filesystem other than FAT32, you might have to specify the necessary filesystem modules in the boot parameters.<br />
<br />
To do so, mount the {{{1|flash medium}}} and change the {{Path|syslinux.cfg}} file line from <br />
append initrd=/boot/grsec.gz alpine_dev=usbdisk:vfat modules=loop,cramfs,sd-mod,usb-storage quiet<br />
to<br />
append initrd=/boot/grsec.gz alpine_dev=usbdisk:'''ext3''' modules=loop,cramfs,sd-mod,usb-storage''',ext3''' quiet<br />
in the case of an ext3 formatted partition. A similar procedure might apply to other filesystems (if they are supported by syslinux and the Alpine Linux kernel).</div>Dlinhttps://wiki.alpinelinux.org/w/index.php?title=Include:Copying_Alpine_to_Flash&diff=12662Include:Copying Alpine to Flash2016-04-11T06:19:54Z<p>Dlin: /* Determine the Device Name of the {{{1|Flash Medium}}} */ added fdisk & blkid method</p>
<hr />
<div>=== Boot Alpine Linux CD-ROM ===<br />
# Insert the Alpine Linux CD-ROM into a computer.<br />
# Boot the computer from the Alpine Linux CD-ROM.<br />
#* This step may require changes to the BIOS settings to select booting from CD. <br />
# Login with the username ''root''. No password is needed.<br />
<br />
{{Tip|If you're not able to boot from the CD, then another option is to boot from a regular Alpine installation, and [[Burning_ISOs|manually mount the ISO image to {{Path|/media/cdrom}}]].}} <br />
<br />
=== Determine the Device Name of the {{{1|Flash Medium}}} ===<br />
Determine the name your computer uses for your {{{1|flash medium}}}. The following step is one way to do this.<br />
# After inserting the {{{1|flash medium}}}, run the command:<br />
#* {{Cmd|dmesg}}<br />
#* At the end of this command you should see the name of your {{{1|flash medium}}}, likely starting with "sd". (For example: "sda").<br />
#* The remainder of this document will assume that your {{{1|flash medium}}} is called /dev/sda<br />
# Use "fdisk -l" or "blkid" to check the device name by size or label<br />
<br />
=== Format {{{1|Flash Medium}}} ===<br />
Run fdisk (replacing sda with your {{{1|flash medium}}} name):<br />
{{Cmd|fdisk /dev/sda}}<br />
<br />
# (''Optional'') - Create new partition table with one FAT32 partition<br />
#* '''d''' Delete all partitions (this may take a few steps)<br />
#* '''n''' Create a new partition<br />
#* '''p''' A primary partition<br />
#* '''1''' Partition number 1<br />
#** Use defaults for first and last cylinder (just press [Enter] twice).<br />
#* '''t''' Change partition type<br />
#* '''c''' Partition type (Win95 FAT32/LBA)<br />
#Verify that the primary partition is bootable<br />
#* '''p''' Print list of partitions<br />
#* If there is no '*' next to the first partition, follow the next steps:<br />
#** '''a''' <big>Make the partition bootable (set boot flag)</big><br />
#** '''1''' Partition number 1<br />
#'''w''' Write your changes to the device<br />
<br />
=== Add Alpine Linux to the {{{1|Flash Medium}}} ===<br />
To boot from your {{{1|flash medium}}} you need to copy the contents of the CDROM to the {{{1|flash medium}}} and make it bootable. Those two operations can be automated with the [[setup-bootable]] tool or can be done manually.<br />
<br />
See also notes to [http://it-offshore.co.uk/linux/alpine-linux/48-alpine-linux-usb-stick-kvm create an Alpine Linux USB stick from within KVM] with [[setup-bootable]].<br />
<br />
{{Note|If the following commands fail due to 'No such file or directory', you may have to remove and reinsert the {{{1|flash medium}}}, or even reboot, to get /dev/sda1 to appear}}<br />
<br />
==== Automated ====<br />
{{Tip|If using Alpine Linux 1.10.4 or newer, you can use this section to complete the install. Otherwise, follow the Manual steps below.}}<br />
{{Note|The target partition has to be formatted. Use the <code>mkdosfs</code> command from the Manual steps below if needed.}}<br />
# Run the [[setup-bootable]] script to add Alpine Linux to the {{{1|flash medium}}} and make it bootable (replacing sda with your {{{1|flash medium}}} name):<br />
#: {{Cmd|setup-bootable /media/cdrom /dev/sda1}}<br />
{{Note|If you get something like '<code>Failed to mount /dev/sda1 on /media/sda1</code>' when running the above [[setup-bootable]] command, you might want to try running:<br />
{{Cmd|modprobe vfat}}<br />
and then try re-run the [[setup-bootable]] command as described above.}}<br />
{{Warning|If you are installing to a USB Stick, you may need to modify the {{Path|syslinux.cfg}} file to say <code>usbdisk</code> as [[#Wrong_Device_Name|described below]], or you will face possible problems booting and definite problems with the package cache. Recent versions of <code>setup-bootable</code> will specify the alpine_dev using a UUID instead, so it should work properly by default.}}<br />
<br />
==== Manual ====<br />
# (''Optional'') - If you created a new partition above, format the {{{1|flash medium}}} with a FAT32 filesystem (replacing sda with your {{{1|flash medium}}} name):<br />
#: {{Cmd|apk add dosfstools<BR>mkdosfs -F32 /dev/sda1}}<br />
# Install syslinux and MBR (replacing sda with your {{{1|flash medium}}} name):<br />
#: {{Cmd|{{{|apk add syslinux<BR>dd if=/usr/share/syslinux/mbr.bin of=/dev/sda}}}<BR>syslinux /dev/sda1}}<br />
#Copy the files to the {{{1|flash medium}}} (replacing sda with your {{{1|flash medium}}} name):<br />
#: {{Cmd|<nowiki>mkdir -p /media/sda1<br />
mount -t vfat /dev/sda1 /media/sda1<br />
cd /media/cdrom<br />
cp -a .alpine-release * /media/sda1/<br />
umount /media/sda1</nowiki>}}<br />
# (''Optional'') Remove any apkovl files that were transfered as part of the copy process. This should be done if you wish to have a fresh install. Replace sda with your {{{1|flash medium}}} name)<br />
#: {{Cmd|<nowiki>mount -t vfat /dev/sda1 /media/sda1<br />
rm /media/sda1/*.apkovl.tar.gz<br />
umount /media/sda1</nowiki>}}<br />
<br />
== Troubleshooting ==<br />
=== Wrong Device Name ===<br />
If you cannot boot from the {{{1|flash medium}}} and you see something like:<br />
Mounting boot media failed.<br />
initramfs emergency recovery shell launched. Type 'exit' to continue boot<br />
then it is likely that the device name in {{Path|syslinux.cfg}} is wrong. You should replace the device name in this line:<br />
append initrd=/boot/grsec.gz alpine_dev='''usbdisk''':vfat modules=loop,cramfs,sd-mod,usb-storage quiet<br />
with the proper device name.<br />
* For boot from USB, the device name should be 'usbdisk' (as shown above)<br />
* For other options, you can run <code>cat /proc/partitions</code> to see the available disks (i.e. 'sda' or 'sdb')<br />
<br />
=== Non-FAT32 Filesystems ===<br />
When your {{{1|flash medium}}} is formatted with a filesystem other than FAT32, you might have to specify the necessary filesystem modules in the boot parameters.<br />
<br />
To do so, mount the {{{1|flash medium}}} and change the {{Path|syslinux.cfg}} file line from <br />
append initrd=/boot/grsec.gz alpine_dev=usbdisk:vfat modules=loop,cramfs,sd-mod,usb-storage quiet<br />
to<br />
append initrd=/boot/grsec.gz alpine_dev=usbdisk:'''ext3''' modules=loop,cramfs,sd-mod,usb-storage''',ext3''' quiet<br />
in the case of an ext3 formatted partition. A similar procedure might apply to other filesystems (if they are supported by syslinux and the Alpine Linux kernel).</div>Dlinhttps://wiki.alpinelinux.org/w/index.php?title=Create_a_Bootable_Compact_Flash&diff=12661Create a Bootable Compact Flash2016-04-11T06:17:19Z<p>Dlin: /* Requirements */ notice the security issue.</p>
<hr />
<div>This process applies to Alpine Linux 1.9.0 or later, and results in a '''run-from-ram''' style installation. <br />
<br />
= Requirements =<br />
In order to follow this document, you will need:<br />
* Alpine Linux CD-ROM ([[Downloads|Download]] a .iso file containing an Alpine release.)<br />
* Computer with CF card reader<br />
* CF card<br />
{{Note|Some CF card readers have problems with the faster CF cards on the market. If you experience problems booting the CF card even after checking BIOS settings, you may need to use an older card.}}<br />
{{Note|This method will keep your private data on CF card, this security issue is a trade-off.}}<br />
{{:Include:Copying Alpine to Flash|CF Card}}<br />
<br />
= DMA Support =<br />
Many CF card readers don't support DMA correctly, so you may need to add ''nodma'' to the ''append'' line of the syslinux.cfg file.<br />
<br />
== See Also ==<br />
{{:Include:Installing_Alpine_see_also}}<br />
<br />
[[Category:Installation]]</div>Dlinhttps://wiki.alpinelinux.org/w/index.php?title=Creating_an_Alpine_package&diff=12616Creating an Alpine package2016-04-10T16:11:25Z<p>Dlin: Added AUR</p>
<hr />
<div>== Requirements ==<br />
<br />
To build package for Alpine Linux you need an Alpine Linux installation. Check the [[Installation]] page to see all available installation options.<br />
<br />
== Setup your system and account ==<br />
{{:Include:Setup_your_system_and_account_for_building_packages}}<br />
<br />
== Getting some help ==<br />
<br />
It might be wise to start by checking what the [[Abuild|abuild]] program can/cannot do.<br />
<br />
{{Cmd|abuild -h}}<br />
<br />
== Creating an APKBUILD file ==<br />
<br />
=== Use a template APKBUILD ===<br />
<br />
To create the actual APKBUILD file {{Pkg|newapkbuild}} can serve you a template to start with. It will create a directory with the given package name, place an example/template APKBUILD file to the given directory, and fill some variables if those are provided. Please check the [[Package_policies| package policies]] page about naming details.<br />
<br />
If you doubt to which repository your package belongs to you can safely use '''testing'''. Building package in your aports/testing directory is not mandatory but this way the package is already at the right place.<br />
<br />
{{:Include:Newapkbuild}}<br />
<br />
{{Note|On older Alpine systems, abuild -c -n ''packagename'' was the way to create APKBUILD files. The 'packagename' was a parameter to the -n option so order of -c and -n matters. }}<br />
<br />
[[Abuild_and_Helpers#apkbuild-cpan|apkbuild-cpan]] simplifies the creation of perl packages from CPAN and [[Abuild_and_Helpers#apkbuild-pypi|apkbuild-pypi]] ease the generation of APKBUILD files for python packages from PyPi. <br />
<br />
If you are create a daemon package which needs initd scripts you can add the -c making it: <br />
<br />
{{Cmd|newapkbuild -c ''packagename''}}<br />
<br />
This will copy the sample initd and confd files to the build directory.<BR><br />
A third file sample.install file will be copied as well (we will discuss this later on).<br />
<br />
=== Modify your APKBUILD ===<br />
Edit APKBUILD and fill in the needed info (especially pkgname, pkgver, pkgdesc, url, license, depends and source). <br />
<br />
If you are going to use any of the variables for directories like $pkgdir, always make sure they are double quoted like: <br />
<br />
"$pkgdir"/somedir<br />
<br />
This will prevent issues with spaces/special characters in the future. <br />
<br />
{{Note|If you like syntax highlighting we suggest you to install vim. We have setup vim to recognize the APKBUILD file as a bash scripts so its easier to read them.}}<br />
<br />
=== APKBUILD variables/functions ===<br />
<br />
==== source ====<br />
<br />
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 [[Creating an Alpine package#install|install variable]]), patches, and all other necessary files.<br />
<br />
Here are few things to note:<br />
<br />
* 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:<br />
: {{cmd|abuild checksum}}<br />
: {{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.}}<br />
<br />
* When the remote file is hosted at SourceForge, it's best to specify the special mirrors link used by SourceForge:<br />
: <pre>http://downloads.sourceforge.net/$pkgname/$pkgname-$pkgver.tar.gz</pre><br />
: (or similar depending on the package).<br />
<br />
* When the remote filename is not specified in the URI (ie, does not end in '/software-1.0.tar.gz'), such as:<br />
: <pre>http://oss.example.org/?get=software&ver=1.0</pre><br />
: You must prepend 'saveas-' to the protocol and append '/software-1.0.tar.gz' (for instance) to the end of the URI, like so:<br />
: <pre>saveas-http://oss.example.org/?get=software&ver=1.0/software-1.0.tar.gz</pre><br />
: This causes the file to be saved as ''software-1.0.tar.gz'' where abuild can use it, instead of ''?get=software&ver=1.0'', where abuild cannot use it.<br />
<br />
* Some projects didn't provide a release tarball. If you point source to an tarball provided by a git web interface (gitweg, cgit, github), such as:<br />
: <pre>http://repo.or.cz/w/gitstats.git/snapshot/ad7efbb9399e60cee6cb217c6b47e604174a8093.tar.gz</pre><br />
: You will run into issues because the checksum changes when downloading on the build system.<br />
<br />
* abuild currently supports the following protocols for remote file retrieval:<br />
** http<br />
** https<br />
** ftp<br />
<br />
<!--: {{Note|If the you want to download from https, you need GNU wget installed on your system.}}--><br />
<br />
* abuild currently supports the following archive types/archive file extensions:<br />
** .tar.gz / .tgz<br />
** .tar.bz2<br />
** .tar.lzma<br />
** .tar.xz<br />
** .zip<br />
<br />
==== depends &amp; makedepends ====<br />
<br />
Depends are the actual running dependencies that a package would need when it is running. Makedepends are only needed when you are building a package. If you set a package, in depends you do not need to add it to makedepends as well. The best way to find out what the depends and makedepends of a package are is to [http://en.wikipedia.org/wiki/Rtfm RTFM]. <br />
<br />
No kidding, lots of important information can be found it the package INSTALL and README file (or the likes). Another good way is the run <code>./configure --help</code> from the source directory to see which options are needed for configure to finish without errors. If you do not yet have a source directory you can create one with the command: <br />
<br />
{{Cmd|abuild unpack}}<br />
<br />
Running <code>configure</code> will also show you how you can disable a specific option for this package. A good example is for instance "--disable-nls" which will disable native language support and thus does not depend on gettext (libiconv, glib, ...). <br />
<br />
Alpine likes to keep things small, so we try to disable as much as possible without losing too many features. The exact disable/enable options are decided the package builder but please try to follow Alpine's design concept as much as possible.<br />
<br />
An easy way of quickly finding out the build info for a package is to check Arch Linux (Alpine package management and build scripts are similar) or Gentoo Linux ebuilds (previous versions of Alpine were based on Gentoo).<br />
<br />
* [http://www.gentoo-portage.com Search ebuilds] <br />
* [http://sources.gentoo.org/viewcvs.py/gentoo-x86/ Gentoo CVS] <br />
* [http://www.archlinux.org/packages/search/ Arch Linux packages] [https://aur.archlinux.org/ Arch Linux User Repository]<br />
<br />
After the package is successfully compiled and created we should make sure it didn't link to any package that is not present in the <code>$depends</code> variable. We do this by using <code>scanelf</code>. If scanelf is not yet installed on your system you can do that by installing {{Pkg|pax-utils}}.<br />
<br />
{{Cmd|scanelf -nR pkg}}<br />
<br />
An example output of {{Pkg|libcurl}} would be: <br />
<br />
ET_DYN libssl.so.0.9.8,libcrypto.so.0.9.8,libz.so.1,libc.so.0,ld-uClibc.so.0 pkg/usr/lib/libcurl.so.4.1.1<br />
<br />
You can see the needed files and should be able to find out which file belongs to which package.<br />
<br />
==== license ====<br />
<br />
The '''license''' tag must reflect the license of the source code. Please check the source tarball for COPYING, LICENSE, or other files with names that indicates that it contains licensing information. Beside the license file most developer include headers in the source code files with licensing details. Please use the short name and the release number in the license tag, e.g <br />
<br />
{| cellpadding="5" border="1" class="wikitable"<br />
|- <br />
! Short name<br />
! Full name<br />
|-<br />
| GPL2<br />
| GNU General Public License Version 2.0<br />
|-<br />
| LGPL2+<br />
| GNU Lesser General Public License Version 2.1<br />
|-<br />
| ASL 2.0<br />
| Apache License Version 2.0<br />
|-<br />
| BSD<br />
| BSD License<br />
|-<br />
| MIT<br />
| MIT license<br />
|-<br />
| MPL 2.0<br />
| Mozilla Public License v2.0<br />
|-<br />
| ZPL 2.0 <br />
| Zope Public License v 2.0<br />
|-<br />
| PHP<br />
| PHP License v3.0<br />
|-<br />
| zlib<br />
| zlib/libpng License<br />
|-<br />
|}<br />
<br />
For the GNU General Public License the '+' means ''or (at your option) any later version.'' which covers future releases of that license. We skip the ''v'' because it's obvious that the number shows the version. If you are unsure about the short name of a license, please check the resources below for additional information.<br />
<br />
* [https://wiki.archlinux.org/index.php/Licenses ArchLinux and Licensing] <br />
* [https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses Fedora and Licensing]<br />
<br />
If a package has a special/custom license we need to provide it with the release. Because we want to save space and don't like to have licenses all over our system we have decided to include the license in the doc subpackage. Please follow the following guidelines to add a proper license. Locate the license file inside the source package. Add the doc subpackage to the $subpackages variable as follows: <br />
<br />
subpackages="$pkgname-doc"<br />
<br />
Add a similar line to the following to your package() function, depending on the license description file: <br />
<br />
install -Dm644 COPYING "$pkgdir"/usr/share/licenses/$pkgname/COPYING<br />
<br />
If you follow these steps then abuild will automatically add the license to the package-doc apk for you.<br />
<br />
==== arch ====<br />
<br />
The package architecture(s) to build for. This can be one of: ''x86, x86_64, all,'' or ''noarch'', where ''all'' means all architectures, and ''noarch'' means it's architecture-independent (ie, a pure-python package).<br />
{{Tip|To determine if your APKBUILD can use ''noarch'', build the package for your architecture and then run "scanelf -R pkg" from the directory that the APKBUILD resides in, in order to scan for ELF files in the ''./pkg'' directory. If you do NOT get output from this, then ''noarch'' can be used.}}<br />
<br />
==== url ====<br />
<br />
Website address for the program. This is usefully later on when either finding documentation or other information about the package.<br />
<br />
==== pkgdesc ====<br />
<br />
A brief, one line, description of what the package does. Useful for the package management system.<br />
<br />
Here is an example from apk_info for the OpenSSH client package<br />
<br />
pkgdesc="Port of OpenBSD's free SSH release - client"<br />
<br />
==== pkgver ====<br />
<br />
Provide the release number of the package you are building.<br />
<br />
==== pkgrel ====<br />
<br />
The $pkgrel versioning is made so if you change something to your APKBUILD file without changing the actual $pkgver you can higer pkgrel so apk tools will detect it as an update. For instance if you forget to add a dependency you can add it afterward and you can +1 pkgver so apk finds this update and add the missing dependency. When there's an upstream version changes, we reset the pkgrel to 0.<br />
<br />
==== pkgname ====<br />
<br />
The base name of the package you are creating. For Freeswitch 1.0.6, you would use "freeswitch"<br />
<br />
==== install ====<br />
<br />
There are 6 different kinds of install scripts. Each script is called with the $pkgname.''<action>'' where ''<action>'' is one of the following:<br />
<br />
<dl><br />
<dt>$pkgname.pre-install<br />
<dd>This script is executed before package is installed. Typical use is when package needs a user/group to be created. For example:<br />
<pre><br />
#!/bin/sh<br />
adduser -H -s /bin/false -D clamav 2>/dev/null<br />
exit 0<br />
</pre><br />
Note the ''exit 0'' at the end. If the script exits with failure (if the user already exist), the package will not be installed and <code>apk add</code> will exit with failure.<br />
<br />
<dt>$pkgname.post-install<br />
<dd>This script is executed after package is installed. Can be used to generate font cache and similar.<br />
<br />
<dt>$pkgname.pre-upgrade<br />
<dd>Same as pre-install but is executed before upgrading an already installed package.<br />
<br />
<dt>$pkgname.post-upgrade<br />
<dd>Same as post-install but is executed after upgrading an already installed package. <br />
<br />
<dt>$pkgname.pre-deinstall<br />
<dd>This script is executed before uninstalling a package. If script exits with failure apk will not uninstall the package.<br />
<br />
<dt>$pkgname.post-deinstall<br />
<dd>This script is executed after a package have been uninstalled. Can be used to update font caches and restore busybox links. For example:<br />
<pre><br />
#!/bin/sh<br />
busybox --install -s<br />
</pre><br />
<br />
</dl><br />
<br />
If the package have an pre-install and post-install script the APKBUILD should have the ''install'' variable defined and the scripts should also be added to the source variable:<br />
<pre><br />
...<br />
install="$pkgname.pre-install $pkgname.post-install"<br />
source="http://....<br />
$install"<br />
...<br />
</pre><br />
<br />
==== subpackages ====<br />
<br />
$subpackages are made to split up the normal "make install" into separate packages. The most common subpackages we use are doc and dev. Because we like to keep our target system small we move documentation and development files (only needed when building packages) into separate packages. To use the specific program a user only need to install the base apk without package-doc or package-dev, but if he wants to read the manual he will need to install package-doc. <br />
<br />
The easiest way to find out if you need to use -dev and -doc is to first build the package without these options set and wait until the build finishes. When its finished you should have a pkg directory which is the fake root directory. Inside this directory you will see the structure as how it would be installed in / on the target system. <br />
<br />
To see if you need the -dev package you can run the following cmd: <br />
<br />
{{Cmd|find pkg/usr/ -name '*.[acho]' -o -name '*.la'}}<br />
<br />
If this returns any files you need to include the -dev package. <br />
<br />
<br> To see if you need the -doc package you can run the following cmd: <br />
<br />
{{Cmd|find pkg/usr/share -name doc -o -name man -o -name info -o -name html -o -name sgml -o -name licenses}}<br />
<br />
If this returns any directories you need to include the -doc package. <br />
<br />
===== Custom subpackages =====<br />
<br />
Some software additionally has non-essential files that do not qualify as either documentation or development content. These files should be placed in their own, specialized subpackage(s). Some packages include large test suites which are only needed in specific circumstances or binaries which have depends which we prefer not to install. To handle those we create our own package/function. In the APKBUILD below the build() function we create another function: <br />
<br />
test() {<br />
mkdir -p "$subpkgdir"/usr<br />
mv "$pkgdir"/usr/package-test "$subpkgdir"/usr/<br />
}<br />
<br />
<br />
We also need to add the package info to $subpackages variable: <br />
<br />
subpackages="$pkgname-doc $pkgname-dev $pkgname-test"<br />
<br />
After we finish building the package you should see another apk called packagename-test.apk which includes the files which we moved to the $subpkgdir dir. <br />
<br />
The above mentioned variables can also be used in our custom function. If we want for instance to build the test() function with perl support we would add: <br />
<br />
depends="perl"<br />
makedepends="perl-dev"<br />
<br />
If we would install the base package it would not install perl, but if we install the package-test package it would.<br />
<br />
==== Patches ====<br />
<br />
Please make sure you always submit human readable patches. Way's to create them are: <br />
<br />
directory compare: <br />
<br />
{{Cmd|diff -urp original_directory new_directory &gt; filename.patch}}<br />
<br />
file compare: <br />
<br />
{{Cmd|diff -up original.file new.file &gt; filename.patch}}<br />
<br />
If you are going to use multiple patches for a single package, the preferred way to handle those is a loop and numbering the patches. <br />
<br />
for i in "$srcdir"/*.patch; do<br />
msg "Applying ${i}"<br />
patch -p0 -i $i || return 1<br />
done<br />
<br />
Because multiple patches can patch the same file, we could create offset for the next patch. To make sure we always patch in a specified way we should number the patches as followed: <br />
<br />
10-patch1.patch 20-patch2.patch 30-patch3.patch<br />
<br />
This way we are always sure patch 1 is first and if we want to add additional patches between them we can use 11,12,21,22... <br />
<br />
==== Configure options ====<br />
<br />
Alpine has some default configure options we set by default. We use /usr for prefix to make sure everything is installed with /usr in front of it. If you notice that anything is installed in the wrong directory please run {{Cmd|./configure --help}} and see if you can set the correct location. <br />
<br />
We are not covering the depend switches here we have discussed this already in the depend section.<br />
<br />
{{Tip|Common steps for building package contain ''./configure'', ''make'' and ''make install''. Everyone of them should be enclosed by ''&#124;&#124; return 1'' to check exit status. Otherwise even if previous step fails e.g. ''./configure'', next will be launched e.g. ''make''. This complicates identifying the point where the build breaks. The same applies to installing additional files.}}<br />
<br />
==== Make options ====<br />
<br />
If you notice weird problems when compiling or installing the package with make/make install you could try to disable [http://www.gnu.org/software/make/manual/make.html#Parallel parallel] building/installing. A normal make line would be: <br />
<br />
make || return 1<br />
<br />
To disable parallel we use: <br />
<br />
make -j1 || return 1<br />
<br />
We can use the same for make install. <br />
<br />
Because we do not want to install the package in our build environment but we want to install it in a fake root directory we need to tell 'make install' to use another destination directory instead of '/'. We do this by setting a variable when we execute make install as followed: <br />
<br />
make DESTDIR="$pkgdir" install<br />
<br />
Please note that some Makefiles do not support this variable and will always install software in '/'. To make sure you do not mess up your build system NEVER run your build system as root but always use a custom user and sudo when needed. If by accident the Makefile does not support DESTDIR variable it will fail to install in our build system system directories.<br />
<br />
==== _builddir ====<br />
If you used <tt>newapkbuild</tt> to create your APKBUILD file, you must specify the path to your unpacked sources. Inside the sections during the prepare/build/install process ''_builddir'' is used. Most of the time a combination of ''$srcdir'' and ''$pkgname-$pkgver'' will work. When not, check the /src directory or the source tarball for the right string. Especially when you are working with automatically generated tarballs (like from github and gitorious), this needs to be adjusted.<br />
<br />
_builddir="$srcdir"/$pkgname-$pkgver<br />
<br />
==== Additional files ====<br />
<br />
If you want/need to install additional files not mentioned above you can use the following cmd (this is an example of a conf file): <br />
<br />
install -Dm644 doc/$pkgname.conf "$pkgdir"/etc/$pkgname.conf<br />
<br />
== Build the package ==<br />
<br />
If you did not already create the checksums as mentioned above you can do so now: <br />
<br />
{{Cmd|cd $pkgname<br />
abuild checksum}}<br />
<br />
It's about time we build our package. Because a build system should never have all the package installed to prevent linking to packages we don't want it to link we use a abuild recursively with the '''-r''' switch. It will install all dependency's from your repository and builds it, afterwards it will uninstall all those depending packages again. You could also use the '''-R''' switch which would build your package including the dependency packages. <br />
<br />
{{Cmd|abuild -r}}<br />
<br />
== Commit your work ==<br />
<br />
After you successfully build your package you can submit your APKBUILD to alpine git repository. <br />
<br />
Update your git repo, before adding new files: <br />
<br />
{{Cmd|cd $aportsdir<br />
git pull}}<br />
<br />
This should pull all the changes made by others into you local git repo.<br />
<br />
When you think you are ready you can add your files to git: <br />
<br />
{{Cmd|cd $aportsdir<br />
git add testing/$pkgdir (include any other files needed for the build; $pkgname.install...)<br />
git commit}}<br />
<br />
In the commit message, add the following (remove the comments in the last four lines):<br />
<br />
{{Cmd| # Please enter the commit message for your changes<br />
#[snip]<br />
#<br />
testing/$pkgname: new aport # this will be the subject line<br />
# a blank line<br />
$pkgurl # homepage of project<br />
$pkgdesc # a one line description}}<br />
<br />
<br />
Now your changes are only available locally in your repository.<br />
<br />
Because you do not have push rights to the Alpine aports repository you need to create diff (patch) of the changes you made and send this patch to the <br />
[http://lists.alpinelinux.org/alpine-devel/ alpine-devel mailinglist].<br />
<br />
To create a diff patch<br />
<br />
<br />
{{Cmd|git format-patch HEAD^}}<br />
<br />
or if you have sprunge, you can create a link to your patch for convenience<br />
<br />
{{Cmd|git format-patch HEAD^ --stdout <nowiki>|</nowiki> sprunge}}<br />
<br />
== Send a patch ==<br />
<br />
[[Creating_patches#Only_the_last_commit_with_.27git_send-email.27|git send-email]] will do that for you.<br />
<br />
== See Also ==<br />
* [[APKBUILD Reference]]<br />
* [[APKBUILD examples]]<br />
* [[Development using git]]<br />
<br />
[[Category:Development]]</div>Dlin