aports

What the repository holds

The aports repository contains the APKBUILD files for each and every Alpine Linux package, along with the required patches and scripts where they exist. It also contains extra files and directories related to testing and building those packages on GitLab through GitLab CI. In Alpine's packaging model, an APKBUILD is the shell script that declares a package's version, source, build steps, and dependencies, and the build system turns it into an apk file. Having every package definition in one tree is what lets the distribution be rebuilt and audited as a whole. The README notes that this GitHub repository is a mirror, and that contributions should go to GitLab or the mailing list rather than GitHub. The extra CI related files mean the same tree that defines packages also drives their automated builds, so a change to an APKBUILD is validated by the pipeline. For a developer, the practical value is a single place to read how any Alpine package is built, from the smallest utility to the largest service. The repository therefore is the backbone of the distribution's packaging, not an application to run. It reflects Alpine's lightweight, script driven approach to packages, where each build is a transparent, reviewable shell script rather than a opaque binary artifact. The mirror on GitHub makes the tree easy to browse, but the real development happens on the Alpine GitLab instance named in the README.

The three repositories

The Alpine aports tree is split into three repositories, each with its own policies. The main repository holds packages that should be supported following the official release cycle, and a package belongs there if it is reasonable to expect it in a basic system and it has a developer assigned to maintain it. Packages in main are expected to include proper documentation when the source ships it and to have test suites enabled when provided. New packages rarely enter main directly; they follow the workflow testing then main. The community repository follows the same release cycle and holds packages that do not belong in main but have finished testing. A community package needs a maintainer and enabled test suites when available, and it should ship documentation when the source provides it. New community packages also follow testing then community. The testing repository does not follow the official release cycle and is not included in official releases; it ships only in the edge branch. Testing is a staging area where packages only need to build correctly, and once verified they should move to main or community. If a testing package is not moved within six months the maintainer is notified, and it is removed after nine months. This graduated workflow keeps unstable work out of releases while giving new packages a clear path inward, and the README explains the policy differences so contributors know where their package belongs.

Contributing and hooks

The README directs contributors to the Alpine contributor guide and asks them to submit a merge request on GitLab or a git patch on the Alpine aports mailing list, noting the mailing list is presently not functional. This reinforces that GitLab is the live development location even though the GitHub copy exists as a mirror. The repository includes git hooks in the .githooks directory, and the README tells you to enable them with git config --local core.hooksPath .githooks after cloning. Those hooks help catch common mistakes before a commit is pushed. The guidelines section links the coding style document for writing APKBUILDs and the commit style document for git commit messages, so contributors have explicit rules to follow. Because the testing repository is the entry point for most new packages, a contributor typically opens a merge request there and lets it graduate. The CI files in the tree then build the package on GitLab, giving fast feedback. For someone packaging software for Alpine, the path is to read CODINGSTYLE.md and COMMITSTYLE.md, write an APKBUILD in the testing directory, and open a merge request on GitLab rather than GitHub. The canonical tree and review process are on gitlab.alpinelinux.org/alpine/aports, while the GitHub repository remains a read only mirror for browsing and reference. The README's brevity matches a mature, policy driven project where the rules live in linked documents.

Editorial conclusion

The repository is a mirror of the Alpine package tree, and the canonical source and merge requests live on GitLab at gitlab.alpinelinux.org/alpine/aports.