APT 3.2 introduces history with undo and rollback in Debian and Ubuntu

  • APT 3.2 becomes the new stable version of the package manager for Debian and derivatives
  • It introduces a transaction history system with commands to list, query, undo, redo, and rollback.
  • Improves the dependency resolution engine and adds performance metrics in JSONL and sleep mode blocking during dpkg
  • It will be available in Debian 14 "Forky" and will also arrive in Ubuntu 26.04 LTS, while it can already be tested in Debian Unstable

APT 3.2

The arrival de APT 3.2 This marks a turning point in package management on Debian-based systems. The new stable version of the classic package manager not only refines internal details but also incorporates features long requested by administrators and advanced users, features previously more associated with other ecosystems like Red Hat. This version arrives almost a year after the version 3.1.

With this release, Debian, Ubuntu and other derivative distributions gain a transaction history with undo and rollback capabilitiesA more refined dependency engine and several improvements focused on day-to-day reliability. All this without turning APT into a completely transactional system, but rather by making a significant leap in ease of use and security when updating.

APT 3.2: New stable version of the Debian package manager

The Debian Project has labeled APT 3.2 as the latest stable version This update to APT's package manager for Debian-based distributions, the component responsible for installing, updating, and removing software on the system, is one of the most extensive functional updates to APT in recent years, with a direct impact on how system changes are managed.

Version 3.2 builds upon the work done in development branches 3.1.6 and 3.1.7, where the foundations of the new history infrastructure were laid. What was experimental in 3.1.7It is now offered as a stable, ready-to-use feature, with a specific set of subcommands for manipulating past transactions.

Transaction history, undo, redo, and rollback

The big change in APT 3.2 is the addition of a transaction history understood semanticallyUntil now, APT was limited to generating simple log files, such as /var/log/apt/history.log, which had to be reviewed manually to reconstruct what had happened in a problematic installation or upgrade.

With the new version, APT stores package operations in a format that can be consult and reuse in a structured wayEach transaction is identified and can be listed, inspected, reversed, or repeated with specific commands, bringing APT closer to concepts common in declarative managers or snapshot-based systems, although without replacing them.

The set of subcommands revolves around the prefix apt history-*Instead of a single generic command, APT 3.2 opts for separate and clear orders for each task, which facilitates its use in scripts and automations, and reduces ambiguity in more complex management environments.

The new history commands in APT 3.2

To handle the new transaction base, APT 3.2 introduces several commands that structure the typical workflow when something goes wrong during an upgrade or installation. The starting point is apt history-list, which shows the list of all registered transactions, with their identifiers and basic data.

Once you have located the change you are interested in, you can consult the details with apt history-info <ID>This report details which packages were installed, removed, or updated during the operation. This information, which previously required wading through logs, is now presented in an organized way, designed for quick review.

If the goal is to reverse a specific operation, then the following comes into play apt history-undo <ID>This command is responsible for undoing the transaction associated with that identifier. If you want to reapply an action that has already been reversed, the equivalent command is apt history-redo <ID>, which repeats the same modification to the system.

When the situation is more serious and it is necessary to return to a previous state of the package set, APT 3.2 offers apt history-rollback <ID>This command attempts to rebuild the system state as it was at the time of the specified transaction, which can save many hours compared to manual reconstruction after a failure in an update chain.

Limits and scope of the new rollback system

Although the functional leap is remarkable, the Debian developers make it clear that APT 3.2 does not make the system fully transactionalThe rollback mechanism is designed for well-defined package operations and cannot solve all imaginable cases in very complex environments or those subject to constant changes.

One of the most important conditions is that older versions of the packages remain available in the repositories. If the software to be restored has disappeared from the sources, the room for maneuver is reduced and the rollback may not be possible or may be incomplete.

In addition, the package maintenance scripts (the well-known scripts of postinst, prerm and companyThese changes can generate side effects that are not always easy to undo automatically. In some circumstances, manual intervention will still be necessary, especially on servers with highly customized configurations.

Therefore, APT 3.2 is presented as a complementary tool to backups and snapshotsnot as a replacement. The new history reduces the impact of many everyday errors and makes life easier on the desktop and in some server environments, but it does not eliminate the need for robust backup strategies.

Practical impact on desktop computers and servers

On everyday computers, the combination of apt history-list y apt history-undo This can make the difference between a scare and a serious problem. If something stops working after an update, the user or administrator now has a fairly direct way to revert changes without resorting to reinstalls or manually searching through logs.

For system administrators managing Debian or Ubuntu server farms, these capabilities provide more control over maintenance windowsIt is possible, for example, to test a change in a specific layer of packages and undo that transaction if unwanted effects are detected, without needing to revert the rest of the updates applied in the same period.

This model is similar to what the DNF manager already offered in the Red Hat environment, reducing one of the historical criticisms of APTDirect integration into the manager itself also eliminates dependence on external tools or custom scripts to reconstruct previous system states.

A smarter dependency engine

Beyond its track record, APT 3.2 reinforces its dependency resolution enginewhich had already been updated starting with the 3.1 series. The new version incorporates improvements designed for sensitive scenarios, such as installations with multiple architectures or repositories that publish binary packages in stages.

One of the notable new features is that the solver has a better understanding of the concept of source package updateThis reduces the risk that, in multi-architecture systems, critical components may be mistakenly removed when the binaries for one architecture are not yet available, a problem that could leave systems in a rather unstable state.

The engine is now also capable of order the dependency alternatives It prioritizes options that are most consistent with the current state and allows, if necessary, the removal of packages marked as manually installed if that is the only reasonable way to resolve conflicts. This flexibility aims to avoid dead ends where the user previously had to intervene piece by piece.

APT 3.2 Sleep Mode Performance Metrics and Lock

Another new feature, less visible to the end user but very useful for monitoring, is the incorporation of performance metrics log in JSONL formatEach line of the log corresponds to an independent JSON object, which simplifies automatic analysis with common observability tools in professional environments.

APT 3.2 also adds a mechanism for prevent the computer from entering sleep mode while it is running dpkgInterrupting an installation or update mid-process because the system goes to sleep could damage the package database or leave components half-configured, a particularly delicate scenario in laptops and computers that rely heavily on energy saving.

With this protection in place, the risk of accidental interruptions to the core of the packaging process is minimized, which will help both home users and administrators managing laptops within organizations.

Availability of APT 3.2 on Debian, Ubuntu and derivatives

According to the Debian Project plan, APT 3.2 will be part of Debian 14 "Forky"whose stable release is expected around the summer of 2027. Thus, when the new version of the distribution reaches the stable repositories, the history and rollback functions will be available by default to all its users.

Prior to that milestone, version 3.2 had already been incorporated into Debian Sid (Unstable)Therefore, those using this development branch can update the package manager and start testing the new features right now, with a simple sudo apt update && sudo apt install apt in their systems.

In the Ubuntu world, Canonical plans to include APT 3.2 in Ubuntu 26.04 LTS “Resolute Raccoon”, whose release is scheduled for April 23, 2026. From that date, users of this extended support version will be able to take advantage of the history and rollback commands directly in an environment designed for long-term stability.

Other distributions based on Debian and Ubuntu will be integrated the new version of APT depending on their own release cycles. In the case of Debian 12, Debian 13, and current stable versions, the adoption of APT 3.2 will depend on whether the maintainers of each branch decide to port the update or keep the package manager as is until the next major version release.