Repositories: Difference between revisions
(Add setup-apkrepos cmd.) |
Prabuanand (talk | contribs) (fixed the upgrading link) |
||
| Line 31: | Line 31: | ||
{{Note|Some Alpine Linux package mirrors may not support '''https'''. If that is the case, you will need to change mirrors or revert back. You can check if your mirror supports '''https''' on https://mirrors.alpinelinux.org }} | {{Note|Some Alpine Linux package mirrors may not support '''https'''. If that is the case, you will need to change mirrors or revert back. You can check if your mirror supports '''https''' on https://mirrors.alpinelinux.org }} | ||
= Release Branches = | = Release Branches = | ||
There are several release branches for Alpine Linux available at the same time. Each May and November we make a release branch from '''edge'''. The '''main''' repository is typically supported for 2 years and the '''community''' repository is supported until next stable release. | There are several release branches for Alpine Linux available at the same time. Each May and November we make a release branch from '''edge'''. The '''main''' repository is typically supported for 2 years and the '''community''' repository is supported until next stable release. Security fixes beyond that can be made on request when there are patches available. | ||
'''To upgrade to the latest release branch, follow the steps in [[Upgrading_Alpine#Upgrading_to_latest_release|'''Upgrading Alpine Linux]]. | |||
== Main == | == Main == | ||
| Line 59: | Line 45: | ||
The '''community''' repository was introduced with Alpine Linux version [https://alpinelinux.org/posts/Alpine-3.3.0-released.html 3.3.0]. ''community'' has a maximum support cycle of 6 months. After that you will need to update to the new release to continue to have support. | The '''community''' repository was introduced with Alpine Linux version [https://alpinelinux.org/posts/Alpine-3.3.0-released.html 3.3.0]. ''community'' has a maximum support cycle of 6 months. After that you will need to update to the new release to continue to have support. | ||
= Edge = | = Edge = | ||
Revision as of 16:56, 3 September 2024
There are three repositories:
- main packages are the software that have direct support and updates from the Alpine core and main team. They also have official special documentation, are always available for all releases and will have substitutions if some are not continued from upstream. Commonly these packages are selected due to their responsibility and stability with respect to upstream availability. Packages from community or (rarely) testing can be accepted into the main repository.
- community packages are those made by users in team with the official developers and close to the Alpine package process. They are supported by those user(s) contributions and could end if the user(s) stops; they may also be removed in a future release due to lack of support by upstream authors. Packages from testing that are accepted go to the community repository.
- testing is where new packages go. These are made by any contributor to Alpine. Testing has no release linked. The testing repository is only available on edge. Packages from testing that are accepted go to the community repository or (rarely) the main repository.
Managing repositories
The package repositories that apk uses to retrieve package files for installation are specified in file /etc/apk/repositories. Each line of this file specifies the location of a package repository, and optionally a tag. Lines that start with a hash character (#) are ignored.
The location may be an http:// or https:// URL, or the path to a directory on the local filesystem. A tagged repository is prefixed with the @tag specifier, followed by a space and the repository location.
The default will look something like:
Contents of /etc/apk/repositories
To automatically configure /etc/apk/repositories, use:
# setup-apkrepos -cf
After making changes to /etc/apk/repositories you should update the package index using:
# apk update
Changing repositories to https
For better security you should probably change the url's from http to https. [1]
Release Branches
There are several release branches for Alpine Linux available at the same time. Each May and November we make a release branch from edge. The main repository is typically supported for 2 years and the community repository is supported until next stable release. Security fixes beyond that can be made on request when there are patches available.
To upgrade to the latest release branch, follow the steps in Upgrading Alpine Linux.
Main
main has a support cycle of 2 years. We also try to limit the amount of packages in main to only include base system packages, in base you can think of packages which are needed by other packages or are needed to setup a basic system. Packages in main must not have dependencies in other repositories.
Community
The community repository was introduced with Alpine Linux version 3.3.0. community has a maximum support cycle of 6 months. After that you will need to update to the new release to continue to have support.
Edge
edge is the name given to the current development tree of Alpine Linux. It consists of an APK repository called edge and contains the latest build of all available Alpine Linux packages. Those packages are updated on a regular basis.

End users should not use edge as their main day-to-day workstation or as a productive system. Because edge is a development branch, many changes are not heavily tested (or tested at all) and packages in edge can and sometimes do break without warning.
However, testing edge is a very valuable activity which helps the Alpine Linux development to ensure that the quality of the stable releases is high. Testing edge is a great way to contribute to the Alpine Linux development.
Upgrading to edge
An upgrade of Alpine Linux from a stable version to the rolling development version edge basically requires the same steps as Upgrading to latest release.
There are only two differences:-
- When editing the /etc/apk/repositories file, all referenced repository versions (such as
v3.22orlatest-stable) therein need to be pointing toedgeas follows.Contents of /etc/apk/repositories
#/media/cdrom/apks http://dl-cdn.alpinelinux.org/alpine/edge/main http://dl-cdn.alpinelinux.org/alpine/edge/community @testing http://dl-cdn.alpinelinux.org/alpine/edge/testing - When the upgrade completes, edge currently issues an encouragement to run a "/usr merge" script that would update the base filesystem hierarchy:
usr_merge_nag.sh: * WARNING: The current system is not /usr-merged. You are encouraged to * migrate manually to ensure the best-possible support. See * https://alpinelinux.org/posts/2025-10-01-usr-merge.html for more details
- Applying this change should not affect general users. For background information on this process, consult the news release, including its listing of the types of installations that may be affected.
- This update is not currently a requirement but will be implemented in the future.
- To attempt its implementation with a dry run first that should foresee errors in execution:
# As per a standard system upgrade to Edge or to a new release doas apk upgrade -aU # Install the script doas apk add merge-usr # Simulate the outcome of the merge: do a "dry run". This would report any errors onscreen doas merge-usr --dryrun # If any error is reported, it would be appreciated if you could kindly open an issue at https://gitlab.alpinelinux.org/alpine/aports/–/issues/new # WARNING: The next step would be to run the script, but it is only to be run as long as the steps above were performed without any errors doas merge-usr # The script would no longer be required and may now be deleted from the system doas apk del merge-usr # Remember to sync and reboot, as per usual after a system upgrade doas sync doas reboot
Testing
The testing repository was introduced with Alpine Linux edge development. No support (staging only) and only built for edge. If it stays here long enough it gets moved to unmaintained/purged (gets cleaned up every 6 months).
Before a package can move from testing to main or community, the following requirements must be met:
- Package must work correctly, including the init.d script (if provided) and default configuration.
- Packaging must be done correctly, with files installed in the right places, e.g. configs are in
/etc/and not in/usr/etc. - Package dependencies are handled correctly. Abuild can (and should) autodetect shared libs, for example sqlite-libs provides so:libsqlite3.so.0. Any package linked to sqlite should have an automatically (by abuild) added
depend=so:libsqlite3.so.0and the user should not have to manually add adepend="sqlite-libs"in the APKBUILD. - There is a maintainer who claims responsibility for the maintenance of the package and can help fix things if they break in the future.
Using the testing repository on stable branches

Edit the file /etc/apk/repositories and add (or uncomment) a line that points to the "testing" directory, while also tagging the repository, for example:
Contents of /etc/apk/repositories
In that case, the tag is @testing, which allows you to pull packages from that repository without potentially messing up your install (too badly):
$ apk add wireguard-go@testing