Repositories: Difference between revisions
Prabuanand (talk | contribs) No edit summary |
Prabuanand (talk | contribs) (moved content from Alpine_Package_Keeper to consolidate repository information) |
||
(3 intermediate revisions by the same user not shown) | |||
Line 28: | Line 28: | ||
# There is a maintainer who claims responsibility for the maintenance of the package and can help fix things if they break in the future. | # There is a maintainer who claims responsibility for the maintenance of the package and can help fix things if they break in the future. | ||
== Release Branches == | == Release Branches == | ||
Line 70: | Line 51: | ||
Similar to [[#Release Branches|release branches]] edge consists of '''main''' and '''community''' repositories in addition to the third repository i.e '''testing'''. | Similar to [[#Release Branches|release branches]] edge consists of '''main''' and '''community''' repositories in addition to the third repository i.e '''testing'''. | ||
== Managing repositories == | |||
The package repositories that <code>apk</code> uses to retrieve package files for installation are specified in file {{path|/etc/apk/repositories}}. To '''automatically''' configure the repositories file {{path|/etc/apk/repositories}}, use the [[Alpine setup scripts#setup-apkrepos|setup-apkrepos]] script: | |||
{{cmd|# setup-apkrepos -cf}} | |||
After making changes to {{path|/etc/apk/repositories}} you should update the package index using: | |||
{{cmd|# apk update}} | |||
Each line of {{path|/etc/apk/repositories}} specifies the location of a package repository, one repository per line and optionally a tag. Lines that start with a hash character (#) are ignored. | |||
The location may be an <code>http://</code> or <code>https://</code> URL, or the path to a directory on the local filesystem. A [[Package_management#Repository_pinning|tagged]] repository is prefixed with the <code>@tag</code> specifier, followed by a space and the repository location. | |||
If you booted from a USB stick ({{Path|/media/sda1}}) or CD-ROM ({{Path|/media/cdrom}}), your repository file probably looks something like this: | |||
{{Cat|/etc/apk/repositories|/media/sda1/apks/}} | |||
In a properly configured Alpine Linux system, the default will look something like: | |||
{{cat|/etc/apk/repositories|#/media/cdrom/apks | |||
http://dl-cdn.alpinelinux.org/alpine/v{{#expr:{{AlpineLatest}}}}/main | |||
http://dl-cdn.alpinelinux.org/alpine/v{{#expr:{{AlpineLatest}}}}/community}} | |||
{{Note| For better security you should probably change the url's from '''http''' to '''https'''. 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 }} | |||
=== Repository pinning === | |||
You can specify additional "tagged" repositories in {{Path|/etc/apk/repositories}}: | |||
{{Cat|/etc/apk/repositories| | |||
https://dl-cdn.alpinelinux.org/alpine/v3.18/main | |||
https://dl-cdn.alpinelinux.org/alpine/v3.18/community | |||
@personal https:/personal-repo.example.com/alpine-apks/ | |||
}} | |||
After which you can "pin" dependencies to these tags using: | |||
{{cmd|apk add application@personal}} | |||
apk will by default only use the untagged repositories, but adding a package with a @tag: | |||
1. will prefer the repository with that tag for the named package, even if a later version of the package is available in another repository | |||
2. ''allows'' pulling in dependencies for the tagged package from the tagged repository (though it ''prefers'' to use untagged repositories to satisfy dependencies if possible) | |||
=== Upgrading to edge === | === Upgrading to edge === | ||
Line 76: | Line 98: | ||
{{:Include:Upgrading to Edge}} | {{:Include:Upgrading to Edge}} | ||
=== Using testing repository | === Using testing repository=== | ||
Installing packages from '''testing''' repository | Installing packages from '''testing''' repository with '''main''' and '''community''' repositories in the '''edge''' branch and submitting '''[https://gitlab.alpinelinux.org/alpine/aports/issues bug reports]''' is one of the best ways to [[Contribute|contribute]] to Alpine Linux. | ||
However installing packages from '''testing''' repository of '''edge''' branch with '''main''' or '''community''' repositories in the '''release branch''' is not guaranteed to work. | |||
Edit the file {{path|/etc/apk/repositories}} and add (or uncomment) a line that points to the "testing" directory, while also [[ | The method explained below is one way to handle this scenario. Do this only if you need package(s) which are available only in '''testing''' repository. | ||
{{Warning|'''Only do this if you're 100% sure what you're doing! and you really need it''' Alpine does not officially support mixing branches this way.}} | |||
Edit the file {{path|/etc/apk/repositories}} and add (or uncomment) a line that points to the "testing" directory, while also [[#Repository_pinning|tagging]] the repository, for example: | |||
{{Cat|/etc/apk/repositories| | {{Cat|/etc/apk/repositories| | ||
Line 91: | Line 117: | ||
In that case, the tag is <code>@testing</code>, which allows you to pull packages from that repository without potentially messing up your install (too badly): | In that case, the tag is <code>@testing</code>, which allows you to pull packages from that repository without potentially messing up your install (too badly): | ||
{{Tip|Check [[ Alpine_Package_Keeper#Check_Dependencies|package dependencies]] for the package in question, before installing it from the tagged repository.}} | |||
{{cmd|# apk add wireguard-go@testing}} | {{cmd|# apk add wireguard-go@testing}} |
Latest revision as of 12:11, 19 September 2024
Repositories
There are three package repositories in Alpine Linux:
Main
Packages in main repository are the software that have direct support and updates from the Alpine core team. Alpine Linux tries to limit the amount of packages in main to only include base system packages, i.e 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.
Packages in main repository 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 in community repository 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.
The community repository was introduced with Alpine Linux version 3.3.0. Packages from testing that are accepted go to the community repository.
Testing
The testing repository is only available on edge branch i.e development branch and this is where new packages go. These are made by any contributor to Alpine. . Packages from testing that are accepted go to the community repository or (rarely) the main repository. Packages in testing have 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.0
and 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.
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 current release branch of Alpine Linux is 3.2.
The main repository of every release branch is typically supported for 2 years. The community repository of any release branch is supported until next stable release i.e six months. 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.
Edge
edge is the name given to the current development tree of Alpine Linux. edge can be considered as rolling release version of Alpine Linux. This version contains the latest build of all available Alpine Linux packages. Those packages are updated on a regular basis.
Since 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.
Similar to release branches edge consists of main and community repositories in addition to the third repository i.e testing.
Managing repositories
The package repositories that apk
uses to retrieve package files for installation are specified in file /etc/apk/repositories. To automatically configure the repositories file /etc/apk/repositories, use the setup-apkrepos script:
# setup-apkrepos -cf
After making changes to /etc/apk/repositories you should update the package index using:
# apk update
Each line of /etc/apk/repositories specifies the location of a package repository, one repository per line 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.
If you booted from a USB stick (/media/sda1) or CD-ROM (/media/cdrom), your repository file probably looks something like this:
Contents of /etc/apk/repositories
In a properly configured Alpine Linux system, the default will look something like:
Contents of /etc/apk/repositories
Repository pinning
You can specify additional "tagged" repositories in /etc/apk/repositories:
Contents of /etc/apk/repositories
After which you can "pin" dependencies to these tags using:
apk add application@personal
apk will by default only use the untagged repositories, but adding a package with a @tag:
1. will prefer the repository with that tag for the named package, even if a later version of the package is available in another repository
2. allows pulling in dependencies for the tagged package from the tagged repository (though it prefers to use untagged repositories to satisfy dependencies if possible)
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.
The crucial difference is, that when editing the /etc/apk/repositories file, all referenced repository versions (such as v3.2
or latest-stable
) therein need to be pointing to edge
.
When using edge branch, testing repository can be added if the packages that one needs are available only in testing repository.
Contents of /etc/apk/repositories
After upgrading to edge, the currently installed edge version may be checked with
$ cat /etc/alpine-release
and referring to the build date that is attached to the release.
Using testing repository
Installing packages from testing repository with main and community repositories in the edge branch and submitting bug reports is one of the best ways to contribute to Alpine Linux.
However installing packages from testing repository of edge branch with main or community repositories in the release branch is not guaranteed to work.
The method explained below is one way to handle this scenario. Do this only if you need package(s) which are available only in testing repository.
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