Package management in Arch Linux has revolved around many years pacman and libalpmBut lately An initiative has emerged that is changing the landscape from the ground up: the project ALPM Written in Rust. This new batch of tools It not only replicates what already existed, but also attempts to redefine how we describe, verify, and automate everything related to packages, repositories, and signatures.
Far from being a simple “Pac-Man replacement”, the ALPM project has become a complete package management framework For Arch and similar distributions. It includes formal specifications, Rust libraries, command-line utilities, Python bindings, a highly flexible linting system, and even a new model for verifying cryptographically signed artifacts. All of this with a very clear focus: security, reproducibility, and modern developer tools.
What is ALPM and why does it matter in Arch Linux?
The term ALPM (Arch Linux Package Management) It refers to the complete packaging process in Arch Linux: obtaining the sources from upstream projects, building them (when appropriate), grouping the results into a specific package format (alpm-packageand distribute those packages to the distribution's users. The format used for the binary packages is open, publicly documented and reusable in other distributions or platforms.
Within this ecosystem, we clearly distinguish between several types of repositories. One alpm-source-repo It is the source code repository (usually a git repo) that contains the scripts PKGBuild and, optionally, a file SRCINFO with metadata derived from PKGBUILD. From that source, one or more package files are constructed. alpm-packageAt the other extreme is the alpm-repo, which is the binary repository (for example, a directory served via the web) with the pre-built packages, their signatures, and the database files alpm-repo-db that describe the state of the repo.
The connection between alpm-source-repo, alpm-package and alpm-repo-db It is based on a network of metadata files: PKGBUILD and SRCINFO in the beginning, BUILDINFO, PKGINFO and ALPM-MTREE inside the package, and later alpm-repo-desc and alpm-repo-files in the repository database. In turn, when the package is installed on a system, the local database alpm-db (managed by libalpm/pacman) stores its own set of files alpm-db-desc and alpm-db-files, maintaining the state of each installed package.
ALPM package lifecycle: from PKGBUILD to system
It all starts in a alpm-source-repo with a PKGBUILDThis script defines the build environment: sources, compilation and runtime dependencies, build steps, testing and installation, as well as basic metadata such as name, version, description, URL, license, and groups. A typical example of PKGBUILD might create a single data file and install it under /usr/share and register a configuration file in / Etc.
A file is generated from that PKGBUILD. SRCINFO which declaratively collects relevant metadata information (pkgbase, pkgname, version, license, architecture, URL, etc.). This representation is designed so that tools like the AUR or automation scripts can easily read the information without executing the PKGBUILD itself, which is key for security and static analysis.
The construction process is normally orchestrated by makepkgwhich relies on the PKGBUILD bash scripts. Ideally, the build should be done in an environment isolated and reproducible (chroots, containers, or virtual machines) containing only the necessary dependencies. Makepkg alone doesn't guarantee an extremely clean environment, so Arch uses... pkgctl, which generates clean chroots using systemd-nspawn and launches makepkg within them. This reduces surprises and improves reproducibility.
During the phase of download and verificationSources (local, remote, or in version control systems) are downloaded and checked against locked checksums (defined in the PKGBUILD). This not only helps ensure that the sources have not been altered, but is one of the cornerstones of the reproducible builds and a clear defense against supply chain attacksIn addition, each origin can be accompanied by a cryptographic signature to authenticate the author.
In many cases they are needed modifications to the sources Before compiling: patches to fix bugs, adjustments for a specific architecture, or changes to better integrate the software into the system. All of this is usually done in a preparation phase after downloading and verification.
The stage of build It handles generating the binaries, translations, and other artifacts: the appropriate compilation system (meson, cmake, autotools, language-specific tools, etc.) is invoked using the dependencies declared in the PKGBUILD. Then, available tests are run to ensure the output works correctly in the target environment.
Finally, in the phase of installation within the temporary treeAll generated files are copied to an empty directory that simulates the root of the target system. ALPM-specific metadata files are also created here. BUILDINFO (detailed description of the construction environment), PKGINF (package metadata, such as version, size, dependencies, or licenses) and ALPM-MTREE (file tree with modes, owners, checksums, etc.). If PKGBUILD generates multiple packages from the same base, multiple output directories are created, and a alpm-package for each of them.
Each output directory generates a ALPM package filewhich is basically an optionally compressed tar file containing the data tree, metadata files (BUILDINFO, PKGINFO, ALPM-MTREE) and, if applicable, an installation script .INSTALL (alpm-install-scriptlet). These packages can be uncompressed or compressed using various technologies: .gz, .bz2, .xz, .zst, .lz4, .lzo, .lz, .lrz, .Zetc., according to the configuration of makepkg.conf (variables COMPRESSBZ2, COMPRESSGZ, COMPRESSZST, PKGEXT, etc.).
Once created, the package can be signed with OpenPGP using separate signaturesThe signature is another file that adds the suffix .sig to the package name (for example, shadow-4.18.0-1-x86_64.pkg.tar.zst.sig). This allows the package manager to later verify authenticity using the packager's OpenPGP certificate.
Internal structure of an ALPM package and related formats
ALPM-based packages clearly distinguish between metadata, scripts, and data filesThe root directory of the tar archive should always contain three files: .BUILDINFO, .MTREE (i.e., ALPM-MTREE) and .PKGINFOThese elements describe the build environment, the attributes of each packaged file, and general package information, and allow both rebuilding the build environment and verifying the installation.
In addition to those required files, there may be a script .INSTALL that acts as alpm-install-scriptletThis script executes actions at specific times (pre/post installation, update or uninstallation) and is a critical point where distributions usually apply specific policies and lints to prevent abuse or unsafe practices.
The rest of the content consists of files from data that is extracted from the root of the system when installing the package. There is no explicit list of allowed paths, but best practices recommend following the systemd file hierarchy standard and the Filesystem Hierarchy StandardAvoid at all costs touching directories that contain user data (for example, nothing in /home). In general, all files and directories in the package are assumed to be owned by root, unless the distribution policy states otherwise.
The formats associated with ALPM are meticulously documented: ALPM-MTREE, BUILDINFO, PKGBUILD, PKGINFO, SRCINFO, alpm-db, alpm-db-desc, alpm-db-files, alpm-package, alpm-package-relation, alpm-package-source-checksum, alpm-repo, alpm-repo-db, alpm-repo-desc, alpm-repo-files, alpm-source-repo, alpm-split-packageamong others. This entire family of specifications defines how a package is described, how its integrity is checked, how dependencies are resolved, and how both binary repositories and the local state of the system are represented.
Local database, repositories, and how pacman works
In the client system, pacman and libalpm They manage a database typically located in /var/lib/pacman. Inside this folder there is a subdirectory local and several subdirectories syncThe first stores information about all packages installed on the system, while the sync directories contain the compressed databases of the configured remote repositories.
Each entry in the local database is a directory per package, whose name combines name and versionTo separate them, a rather fragile convention is used: one looks for the penultimate script in the name (because the last one usually separates the architecture), something that in itself gives an idea of the inherited complexity. In each package directory there are three main files: desc, files and mtreeThe first two use a key block format with %FIELD% markers, while the third is a gzip-compressed mtree.
The file desc It contains the package metadata: name, version, base, description, URL, architecture, build and installation dates, packager, installed size, installation reasons, licenses, validation type, dependencies, etc. The file files It contains the list of files managed by the package on the system. The file mtree It relists those files (and some additional ones from the build) with extended information such as sizes, checksums, permissions, and times.
From the perspective of someone who wants to query the local database efficiently, the design has certain drawbacks: to check if an installed file is still the correct one, you have to read and correlate both files and mtreeNormalizing paths (because they may be represented differently) and filtering elements are crucial. On systems with many packages, this involves opening thousands of small files, resulting in numerous system calls and long read times. Developers who have explored these intricacies in Rust have noted that while it's possible to speed up the process by directly comparing strings, this can be fragile and exclude valid paths.
Despite that complexity, the local database alpm-db It is crucial: it reflects which version of each package is installed, which files it has, which configuration files should be treated as backups (with MD5 checksums), and it maintains a copy of the original ALPM-MTREE, allowing missing or modified files to be detected.
On the binary repositories side, a alpm-repo It combines unique packages (by name and version), their signatures, and a database file. alpm-repo-dbIn the latter, each package is described by a alpm-repo-desc which adds data from PKGINFO, the signature and the package file itself (sizes, checksums, etc.), and a alpm-repo-files which includes the list of routes. Tools such as repo-add These files are managed, and for more complex environments with multiple maintainers, Arch relies on dbscripts, which automates the management of official repos.
Pacman, for its part, downloads the files alpm-repo-db For each configured repository, it compares its contents with the local database and, if it finds newer versions, downloads and installs the corresponding packages. Each installation involves three basic steps: removing the files from the previous version, adding those from the new version, and updating the information in alpm-dbAll of this is supported by the metadata generated during the build and installation phases.
Rust enters the picture: modernizing ALPM and overcoming limitations
In recent years, part of the community has shown interest in Reimplementing the logic of libalpm and pacman in RustThis is especially useful for taking advantage of a richer type model, greater memory safety, and better abstractions. Attempting to wrap libalpm directly from Rust is not trivial: the C library has long-lived APIs with callbacks for progress, downloads, and other events that become difficult to adapt into a fully secure wrapper in Rust.
This has led some developers to propose a ALPM implementation fully in RustWith ambitious goals: to be secure and fast, to replicate the behavior of libalpm, to offer a much more expressive API, and to be cross-platform (including Windows). If achieved, it would open the door to creating tools similar to Chocolatey or more user-friendly package managers based on the Arch package format, without the constraints of existing C APIs.
The exploratory work has focused particularly on the access to the local database and the creation of Rust libraries to read the /var/lib/pacman directories, parse the desc/files/mtree formats, and expose them with safe types. One of the notable improvements is the Lazy load of packagesInstead of reading all packets and their metadata at once (something that can take minutes if files and mtree are thoroughly cross-referenced), the reads are delayed until they are actually needed, allowing one or a few packets to be inspected without massive penalties.
At the same time, the ALPM project itself has opted for an approach bottom-up, focused on reusable librariesBasic crates have been created such as alpm-typeswhich defines low-level types shared by many formats, and alpm-commonwhich offers common traits and utilities. For parsing custom formats, the Parser Combinator Library has been chosen. win now, on which it is built alpm-parsers, a set of reusable tools for managing all these ad hoc files that use the Arch package infrastructure.
Another essential piece is alpm-solve, a new approach to dependency resolution based on the generic library I resolveHere, the aim is to rethink the logic of resolution with a more modern, precise, and extensible model than the legacy of libalpm, which was always based on strong types.
The library has been created for handling compression in repository packages and databases. alpm-compress, which abstracts in an extensible way the different compression algorithms used by the files alpm-package y alpm-repo-dbAnd to handle the packages themselves, the crate alpm-package It allows you to create packages from pre-prepared input directories and, at the same time, easily iterate over data files and extract validated metadata.
A classic problem with packaging is that the The build process needs to create files owned by root (for example, when installing in a tree that simulates /usr, /etc, etc.), but you don't want to run the entire process with superuser privileges. For this scenario, the project offers rootless-run, a library that provides a generic abstraction for executing commands “as root” using backends such as fakeroot o rootlesskitLater, there are plans to integrate it as well. libkrun to provide enhanced isolation via KVM, even in contexts where fakeroot or rootlesskit have limitations.
Specifications, documentation, and tooling surrounding ALPM
One of the most important leaps in quality has been the comprehensive formalization of specifications which define the different formats and processes: alpm-db, alpm-repo, alpm-package, alpm-package-version, alpm-package-name, alpm-architecture, etc. This documentation not only allows you to understand what each file does, but also serves as a robust foundation for creating parsers and validators in Rust, Python, or other languages without having to track down C code or scattered scripts.
These specifications are also distributed as a package alpm-docsso that any developer or maintainer can install and access them locally. Furthermore, the project maintains a updated web documentation where the general architecture, the role of each file, and the relationship between them are explained in an accessible way. The alpm(7) document, for example, is a kind of high-level gateway to the world of package management in Arch.
Several specific tools have been built upon this documentary basis. The crate alpm-srcinfo It offers a library and CLI for parsing, validating, and creating SRCINFO files from PKGBUILD. Since PKGBUILD files are bash scripts with dynamic logic, generating correct SRCINFO files without executing arbitrary code is not trivial. Therefore, it complements the project. alpm-pkgbuild-bridge, the crate alpm-pkgbuild and a translation layer in alpm-srcinfo that allows for a reliable and secure representation of the data.
Similarly, alpm-buildinfo It provides a library and a command-line tool for managing BUILDINFOThe format that describes the build environment and is essential for bit-by-bit replaying builds. This tool allows you to analyze, validate, and generate BUILDINFO files that are then included in the packages.
The format ALPM-MTREE It is managed through the crate alpm-mtreewhich allows parsing, validating, and generating these files. Since it is a subset of the libarchive mtree format and is more of a metalanguage While it's a simple data format, writing relies on bsdtar, but the validation and reading logic resides in Rust. The information contained there serves to verify that the properties of the installed files (permissions, owners, checksums) remain as expected.
For general package metadata, the crate alpm-pkginfo It covers the PKGINFO format: dependencies, alpm-package-relationships, package name, version, architecture, licenses, size, etc. From here, a strongly typed representation of the metadata that was previously scattered in plain text is achieved.
The system's database, alpm-db, it is dealt with by the eponymous crate: alpm-dbThis allows you to parse, validate, and generate alpm-db-desc and alpm-db-files, and works towards an access model with ACID properties, designed to be integrated into applications that need to read or manipulate the database with consistency guarantees.
Another sensitive format is that related to ELF files, in particular the sonames which are used to express binary dependencies. The crate alpm-soname It focuses on managing and extracting information from the formats alpm-sonamev2 (more modern) and, in general, of the sonames defined in binaries and ELF libraries. This makes it easier to link the actual runtime dependencies with the package relationships that then appear in PKGINFO and other structures.
For repository databases, the crate alpm-repo-db manages the files alpm-repo-desc and alpm-repo-filesand is being extended to support the creation, reading, writing, and compression of alpm-repo-db complete, as well as the addition, updating, and deletion of entries. In the medium term, it will be a key component for tools that want to manage repositories programmatically without relying on legacy scripts.
As a testing ground, the project also maintains dev-scriptsA crate without releases designed to test integration with real data: download repositories from official sources and the AUR, obtain binary repos, and allow you to validate that the ALPM libraries behave correctly against large volumes of real packages.
Linting, Python integration, and internationalization
With all this base of specifications and libraries, the natural next step has been to create a ALPM-centric linting frameworkThe crate alpm-lint It acts as the core of this system, with a CLI called alpm-lint(1) and an extensible architecture to add new rules. The idea is to have a single central point that can validate all aspects of package management: from the contents of an alpm-source-repo (PKGBUILD, SRCINFO, patches) to a complete alpm-package or even elements of a repo.
Although the number of lints is small for now, the project encourages Rust maintainers and developers to collaborate in expanding them. Among the goals is integrating alpm-lint into the official Arch build tools so that package quality improves without relying so heavily on manual reviews. Each lint rule is documented in detail, and there is a dedicated website that lists all lints and their meanings, generated from the code documentation.
To facilitate its adoption in Python projects, the team has developed python-alpmBindings that expose parsers and verified types to this language. The main potential consumer is AURwebThe FastAPI application that manages the Arch User Repository currently uses a native Python library for SRCINFO. With python-alpm, you get much more robust parsing, based on the same Rust libraries used by the rest of the ALPM project.
These bindings are already available in PyPI, and work is underway to integrate them into AURweb, gradually replacing previous solutions. Further plans include expanding the coverage of python-alpm to encompass other needs, such as integrations with... archinstall or other services that rely heavily on packet infrastructure.
With regards to CapabilitiesThe project has adopted the framework fluent for managing translatable texts and error messages. The crate was built on top of fluent. fluent-i18nwhich simplifies its use in the project's libraries and CLI. Translations are coordinated using Weblatewith clear guidelines for contributors who want to translate messages into other languages. The idea is that both end users and system administrators who are not fluent in English can obtain clear and useful messages in their language.
VOA: Verification of artifacts without relying on state keyrings
Another important front that the ALPM project addresses is the cryptographic verification of packets and other artifactsTraditionally, Arch uses OpenPGP and a central keyring based on GnuPG to verify both packages and repository metadata. This model, however, has several problems: the keyring is independent of context (does not distinguish between different sets of signatures based on usage), is linked to GnuPG and its specific behavior, is stateful (requires an agent and state management) and, above all, has become problematic as GnuPG has moved away from the IETF-driven OpenPGP standard.
Even before 2024, an alternative was already being explored: instead of using a monolithic keyring, a directory hierarchy with “verifiers”Initially designed only for OpenPGP, it was soon extended to a technology-agnostic approach. From this idea, the specification was born. File Hierarchy for the Verification of OS Artifacts (VOA), which describes how to organize OpenPGP certificates, public SSH keys, or X.509 certificates into a clear tree that indicates in what context each verifier should be used when validating artifacts.
The initial version of this specification, with explicit support for OpenPGP, was published in 2025, and drafts for other backends (SSH, X.509, minisign, signify) are pending refinement. In parallel, the reference implementation in Rust through the VOA project, with several specialized crates.
The crate voa-core It manages the generic processing of the VOA hierarchy, regardless of the technology. It is built upon. voa-openpgpwhich implements concrete verification with OpenPGP. This library supports several verification models: a "plain" mode where artifacts are verified only with available verifiers (filterable by fingerprints or domains in user IDs), a mode based on simple “trust anchors” where the verifiers must be certified by a set of anchors with a minimum number of signatures, and a mode of “Web of Trust” widespread which allows for more complex and decentralized trust configurations.
In all cases you can configure how many independent data firms These are necessary to consider an artifact valid. In the specific case of Arch Linux, the actual model used today is similar to a Single-level Web of TrustThere is a set of certificates that act as master keys (trust anchors), and the packager certificates must have user IDs under the archlinux.org domain and be signed by three or more of these master keys. With voa-openpgp, this policy is best expressed using trust anchors mode with a configurable number of required certificates.
The integration is completed with voa-configwhich defines a configuration format (voa(5)) to describe distribution- or context-specific verification policies, including how verifiers and trust anchors are selected. An example is the Arch configuration file, which declares that for openpgp technology, the following is required: a valid data signature, that the verifiers must have user IDs with the archlinux.org domain and at least three certifications of the master keys, whose fingerprints are explicitly listed.
The crate flies It provides a high-level API for VOA consumers and a CLI for administrators. With the command voa config show You can inspect which settings are applied in a given context (e.g., “arch”), and with VOA Verify Files can be verified along with their detached signatures using the installed verifier hierarchy. Results can also be returned in JSON, facilitating integration into automated pipelines.
To make all of this work practically, there is a package like voa-verifiers-arch which installs the VOA verifiers used by Arch Linux. After installation, for example, you can verify a package from the pacman cache by specifying both the .pkg.tar.zst file and its .sig file, and VOA will confirm that the signature is valid according to the configured policy.
In parallel, the project has investigated the state of the Web of Trust in different implementations and has concluded that legacy solutions have serious limitations when calculating confidence. From this analysis, a new pathfinding algorithm has emerged called BerblomBerblom is specifically designed to calculate trust scores in a general, robust, and efficient way within a certification graph. The intention is to integrate Berblom into the VOA implementation by 2026 to deliver a more robust and predictable Web of Trust.
Funding, statistics and future lines of work
All this effort has been significantly boosted by the Sovereign Tech Fund (STF) financingBetween 2024 and 2025, this allowed for in-depth work on the ALPM project for approximately 15 months. During this time, six major milestones were completed, ranging from the formalization of specifications and the creation of core libraries to advanced cryptographic verification, database management, and developer tooling.
The numbers speak for themselves: hundreds of commits from multiple contributors, tens of thousands of lines of Rust code, scripts, documentation, and configuration files spread across a large workspace. The project's philosophy is clear: creating value beyond Arch Linux, providing generic solutions that can be reused by other free software distributions and projects, without being tied to too narrow a niche.
Although STF funding has ended, ALPM's roadmap remains very much alive. There are plans to significantly expand the set of lints in alpm-lint and study its direct integration into the official build tools. The possibility of offering a C-API compatible with libalpm Based on the new Rust libraries, although for now the priority is for consumers to directly use the finer and well-typed ALPM APIs.
In the area of binary repositories, the intention is to complete the support for alpm-repo-db to cover the entire lifecycle of a repository database: creation, reading, compression, updating, and deletion of entries. At the same time, a layer is to be added for the safe download of devices from alpm-repo, tightly integrating the VOA system for package and database verification using OpenPGP (and, in the future, other backends).
Regarding integrations, one of the objectives is continue expanding python-alpm To cover more use cases, especially applications like archinstall that need flexible and reliable access to the package infrastructure. Developers interested in the Rust/Python crossover are also encouraged to collaborate to make using both technologies together easier.
Thanks to this entire framework of secure types, robust parsers, and verification and internationalization tools, the community now has a much more solid foundation for building new specialized package management applicationsFrom more user-friendly frontends to auditing tools, deployment automation, dependency analysis, and CI/CD system integration, this revamped ALPM ecosystem has become an extremely fertile ground for experimenting, improving, and, above all, building useful things without constantly battling opaque legacy details. For anyone involved in Arch Linux, Rust, or supply chain security, this revamped ecosystem has become an exceptionally fertile ground for experimenting, improving, and, above all, building useful things without constantly battling opaque legacy details.