# Nala: Inspectable APT Transactions Through a Rust CLI

> Nala is a Rust command-line front-end for libapt-pkg that adds review-oriented summaries, transaction history, mirror selection, and optional TUI output to familiar APT operations. The active implementation is a rewrite from the archived Python project, and the README does not document an end-user installation procedure.

**volitank/nala** — Nala is a front-end for libapt-pkg.

- Repository: https://github.com/volitank/nala
- Stars: 1,920 · Forks: 54
- Language: Rust
- License: GPL-3.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/volitank-nala

## Nala's Role Beside libapt-pkg

Nala addresses a command-line problem in Debian package administration: users can invoke APT, but package operations are not always presented in a form that makes the pending transaction easy to inspect before approval. According to the README, Nala keeps APT package semantics while presenting package operations in a way that is easier to inspect before committing changes. Its audience is therefore administrators and Debian users who already understand APT but want more structure around package decisions.

The project is a front-end for `libapt-pkg`, not a replacement package repository. Package inspection commands include `list`, `search`, `show`, and `policy`. System-changing commands cover `install`, `remove`, `autoremove`, `update`, and `upgrade`. Nala also documents local `.deb` installation, direct URL ingestion, glob-style upgrade exclusions, and normal, safe, and full upgrade modes. These features remain tied to the APT environment and its available packages.

The rewrite adds administrative history and interface options around those operations. Applied transactions are stored as individual JSON records, and the history interface supports inspection, `undo`, `redo`, and clearing selected or complete history. Mirror selection is handled through `nala fetch`, including automatic and interactive TUI modes. Package and policy views can produce machine-readable output, while transaction summaries can use full, simple, plain, or TUI-backed presentation.

This makes Nala most plausible for an administrator who wants a different inspection layer around APT. It is a poor fit for systems without the expected APT and libapt-pkg environment, or for users who require a narrowly documented interface limited to direct APT commands.

## Rust Parsing, Configuration, and Terminal Rendering

The active implementation lives under `src/` and uses `rust-apt`. The README says the Rust rewrite introduced a structured command parser, typed configuration, and JSON-friendly internal models. The dependency file gives a clearer view of that path. `clap` defines the command interface, while `serde`, `serde_json`, and `toml` support structured data and configuration. `clap_complete` provides shell completion integration.

The same parser also supplies documentation generation. A Rust build script uses `clap_mangen` to generate manpages from the parser that powers the binary. This reduces the chance of maintaining command documentation independently from command parsing, although the repository does not claim that every help page is automatically regenerated during each ordinary invocation.

Presentation is divided into several paths. `ratatui` and `crossterm` support optional full-screen terminal interfaces, while `comfy-table` supports styled terminal tables. The default `Ui.mode` is `"Auto"`, which selects enhanced inline views when the terminal supports them. `"Tui"` enables the optional full-screen interfaces, and `"Plain"` disables the enhanced terminal UI. For a single invocation, `--tui` selects TUI mode, while `--no-tui` returns a configured TUI setting to automatic inline behavior. This distinction gives administrators a fallback when terminal capabilities do not match the configured interface.

Configuration is loaded from TOML. The README says built-in defaults apply when the default file is absent, but an unreadable or invalid existing file produces an error. Command-line flags override configuration for the current invocation, and APT options can be supplied with `-o KEY=VALUE`. The configuration is stricter than a permissive fallback system: retired and unknown fields are rejected after certain package upgrades.

## A Build Setup and First Package Query

The repository documents development setup rather than a verified end-user installation procedure. Its installation links point to GitLab releases and package downloads, but the README does not explain how to install a downloaded artifact or which package versions are available for each Debian release. The commands below are therefore for building from source, not for installing a prebuilt Nala binary.

First install the documented system requirements. The command installs the C++ build tools, libapt-pkg development headers, `pkgconf`, and the spell checker used by the project.

```bash
sudo apt-get install g++ libapt-pkg-dev pkgconf codespell
```

The repository then documents a normal build and a test command. The build invokes Cargo for the `nala` package, whose manifest selects Rust edition 2024. The serial test setting is explicitly included in the repository instructions and can be used as the first validation step for this libapt-pkg integration.

```bash
cargo build
cargo test -- --test-threads 1
```

The `just` file also provides development toolchain setup. This command installs stable and nightly Rust, including nightly `rustfmt`. It changes the machine's Rust toolchain installations and runs `sudo apt-get install`, so it is appropriate for a configured development host rather than a minimal package-management workstation.

```bash
just setup-dev
```

For a first non-modifying package query, use one of the documented inspection commands. This searches package names for `apt` and does not require a package-changing operation:

```bash
nala search --names apt
```

The README does not specify sample output for that query, so its expected result is an APT-related package listing. Package-changing commands should not be used as the first smoke test because Nala checks for root before operations that modify the system.

## Review, Download, Install, and Record Flow

Nala's package-changing workflow combines explicit review with APT-backed execution. The README states that Nala displays planned changes before committing them, checks for root, records applied transactions in history, and reports when the system marks a reboot as required. These are separate responsibilities: root authorization permits a system mutation, the summary exposes the transaction, the APT path performs package semantics, and history provides a later record.

Shared transaction flags include `--download-only`, `--simple`, `--update`, `--no-update`, `--assume-yes`, `--assume-no`, `--purge`, and `--allow-unauthenticated`. These flags modify behavior or approval handling, so automated use should account for the loss of an interactive review step. `--download-only` is the most direct documented way to stop before installation, although the command still belongs to the package transaction path.

The README also defines special autoremove behavior. Automatic removal remains enabled for interactive transactions. Under `--assume-yes`, Nala skips implicit autoremove unless `--autoremove` is also passed. The explicit `autoremove` and `autopurge` commands are unaffected. That difference is significant because an assumed approval changes what can happen alongside the requested package operation.

For URL packages, Nala accepts a trailing SHA-256 or SHA-512 digest after the URL. The documented form is:

```bash
nala install 'https://example.org/package.deb:HEX_DIGEST'
```

The repository states that downloaded package hashes are verified before installation. It does not document recovery behavior after a hash mismatch, so operators should not assume that retry, bypass, or diagnostic behavior is available without consulting the generated command documentation or source.

Transaction history uses per-entry JSON. The supported inspection and mutation forms include:

```bash
nala history
nala history last
nala history undo last
nala history redo 12
nala history clear 12
nala history clear --all
```

The availability of `undo` and `redo` should not be read as a promise that every APT change can be reversed. External package changes, repository changes, or system operations between entries are outside what the README explains.

## Mirror Selection and Configuration Upgrade Boundaries

Mirror selection is separate from ordinary package installation. The README documents automatic selection, an interactive TUI, HTTPS-only operation, and country filtering:

```bash
nala fetch
nala fetch --auto
nala fetch --https-only --country US
```

The dependency list includes `reqwest` with JSON and SOCKS features, while the README separately states that APT acquire configuration supplies proxy support. These mechanisms serve different paths. Proxy selection belongs to APT acquisition behavior, whereas mirror selection is exposed by Nala's `fetch` interface. The repository does not document a single proxy environment variable, so none should be inferred from this design.

The Debian package treats `/etc/nala/nala.conf` as a conffile. On upgrade, `dpkg` replaces an unmodified packaged file automatically and asks before replacing local changes. If the administrator keeps the older file, Nala directs them to compare it with `/etc/nala/nala.conf.dpkg-dist`. Nala then rejects retired and unknown fields. This creates a deliberate migration boundary between preserving administrator edits and accepting the package's newer schema.

That design is more predictable than silently ignoring an invalid configuration, but it introduces an upgrade task for locally modified files. A site-specific file with removed keys can become invalid after a package upgrade. The administrator must reconcile the retained file with the distribution file before normal operation resumes.

The `include` list in `Cargo.toml` ships `nala.conf`, source, locales, build logic, README, and license text. The repository does not state that every local configuration file is included as a conffile, so administrators should rely on the documented `/etc/nala/nala.conf` path rather than assuming arbitrary local paths are packaged.

## Constraints, Alternatives, and Maintenance Cost

The largest limitation is platform scope. Nala is a front-end for `libapt-pkg`, uses `rust-apt`, and documents Debian-oriented development dependencies and Debian package handling. It is not presented as a portable replacement for package managers used on non-Debian operating systems. Its source also depends on native components, including `libapt-pkg-dev` and a C++ toolchain. Those requirements complicate cross-compilation and adoption outside a compatible Debian build environment.

A second limitation is project maturity and documentation. The README describes the repository as being rewritten from the original Python implementation. Python-era source and documentation remain under `legacy/python`, while active application code lives under `src/`. There are no GitHub releases, and the README has no end-user installation section. The official project links point to GitLab, so the absence of GitHub releases should not be treated as proof that no release artifacts exist elsewhere.

Maintenance is current. The last push was on 2026-10-11. That indicates recent repository activity, but it does not by itself establish API stability or production suitability for a particular deployment.

The real alternative is to invoke APT's own command line instead of Nala. Both operate within APT package semantics. The difference is presentation and workflow: APT's own interface is the baseline path, while Nala focuses on pre-transaction summaries, typed configuration, JSON-friendly records, history operations, machine-readable inspection, and optional TUI views. Operators who require APT's documented command surface should retain that direct path. Operators who need Nala's review-oriented views should account for its rewrite status and native dependencies.

The code is licensed `GPL-3.0-only` in `Cargo.toml`. That affects redistribution and integration obligations for software distributors. This is a project classification, not legal advice.

## Conclusion

Adopt Nala when you administer an APT-based system and want clearer pre-transaction summaries, package history, and terminal-focused output. Do not choose it if you require the documented behavior of APT's own command line or need an end-user installation path documented in this repository. Verify first that `libapt-pkg-dev`, the pinned Rust dependencies, and the terminal environment work on your Debian release. Build the Rust code and run `cargo test -- --test-threads 1` before allowing any command to modify system packages.

## FAQ

### What package manager is Nala a front-end for?

Nala is a command-line front-end for `libapt-pkg` built with `rust-apt`. It retains APT package semantics.

### Does Nala support transaction history and undo?

Nala stores applied transactions as per-entry JSON records. Its history commands support inspection, `undo`, `redo`, targeted clearing, and `nala history clear --all`.

### How do I build Nala from the repository?

The README documents installing `g++`, `libapt-pkg-dev`, `pkgconf`, and `codespell`, then running `cargo build` and `cargo test -- --test-threads 1`. It does not provide an end-user installation procedure for a downloaded release.

### Does Nala verify packages downloaded from a URL?

The README states that package downloads are hash-verified before installation. A direct URL may carry a trailing SHA-256 or SHA-512 digest in the documented `HEX_DIGEST` form.

### What happens when Nala configuration is invalid after an upgrade?

An unreadable or invalid existing configuration file is reported as an error. For `/etc/nala/nala.conf`, the README directs administrators whose local file was retained to compare it with `/etc/nala/nala.conf.dpkg-dist`; retired and unknown fields are rejected.

## Sources

- [Issues](https://github.com/volitank/nala/issues)
- [License: GPL-3.0](https://github.com/volitank/nala/blob/main/LICENSE)
- [README](https://github.com/volitank/nala/blob/main/README.md)
- [volitank/nala on GitHub](https://github.com/volitank/nala)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/volitank-nala