Unified Package Management Backend (Snap, DEB, Flatpak) for Post-26.04

Project Discussion Desktop
1

Hi Ubuntu Desktop Team,

As a Member of Ubuntu Community, I would like to propose a strategic feature for the roadmap following the 26.04 LTS release.

The Problem: Users currently face fragmentation between Snap, DEB, and Flatpak management, often leading to resource locking (apt vs snapd) and a confusing UX in the Software Center.

The Proposal: Implement a Unified Package Management Backend.

Key Technical Objectives:

1. Unified Abstraction Layer: A central middleware to orchestrate transactions across all package formats concurrently.

2. Conflict Resolution: Logic to handle app availability across multiple sources (prioritizing based on user preference).

3. Consolidated Updates: A single update path to prevent dpkg or snapd frontend locks during system maintenance.

This integration would solidify Ubuntu as the most cohesive desktop experience for both developers and general users. I’m looking forward to your technical feedback on this.

Best regards,

Marcel Stevano

4 Likes
2

Linus himself said the thing holding Linux back is package management. Package management should all be done with one application. I agree completely with your proposal.

2 Likes
3

Linus has always emphasized that desktop Linux’s biggest hurdle isn’t the kernel—it’s the fragmented plumbing of app delivery. My proposal for a unified abstraction layer is designed to fix exactly that.

We shouldn’t force users to care about Snap vs. DEB vs. Flatpak. The system should be smart enough to orchestrate these backends invisibly. It’s about building a seamless experience where the UI just works, regardless of the package source. Technical fragmentation shouldn’t be the user’s problem.

2 Likes
4

You are not the first to suggest this. I recall similar ideas two decades ago, and regularly since. Packagekit, for example, comes to mind as a unified abstraction layer.

The fastest and easiest way to get most new/improved software into Ubuntu is for a community project to add the software to Debian first. If the software (or community-improved software) is already in Debian, it will automatically merge into the next release of Ubuntu.

You might consider searching for a community project that already is working on the problem, and contributing some effort there. If you cannot find such a project
start one.

The work priorities of paid Canonical engineers do not come directly from community suggestions. Their work is assigned by their employer. The number of community ideas that they adopt has historically been very small.

1 Like
5

I appreciate the historical context. However, PackageKit was designed for a different era of Linux. Today’s fragmentation (Snap/Flatpak/DEB) creates specific race conditions and resource locks that PackageKit wasn’t built to orchestrate.

While I understand Canonical’s internal priorities, the user experience gap is widening. My proposal isn’t just about ‘adding software’ via Debian; it’s about a modern backend orchestration to fix the ‘resource busy’ deadlocks that average users face daily. If the official roadmap is tight, perhaps it’s time for a more focused community-driven middleware that bridges these formats.

1 Like
6

Bonjour,

Merci pour cette proposition.
Je trouve l’idĂ©e intĂ©ressante et cohĂ©rente avec l’objectif de rendre Ubuntu Desktop toujours plus lisible, fluide et accessible.
La coexistence de plusieurs formats apporte de la souplesse, mais une meilleure orchestration globale serait effectivement un vrai plus pour l’expĂ©rience utilisateur.

Je soutiens donc volontiers cette réflexion.

7

You have forgotten RPM.

I am a Ubuntu user. Does that make me a member of the Ubuntu community? You are making claims about my experience with Ubuntu. Am I not allowed a say in this matter?

I do not experience resource locking. What is it anyway? Neither have I experienced dpkg or snapd frontend locks during system maintenance. Anyway, snapd is a Debian package. It is updated by dpkg/apt.

Jon Seager is Canonical’s vice-president for engineering. Have you read the interview he gave to The Register? The intentions, if not the plans, for the future development of Ubuntu have already been discussed in Canonical. For all I know they might have been written down, if not in stone, but in some electronic format.

I would welcome some technical evidence for the claims you are making about Ubuntu and the experience of its users.

Interview with Canonical’s vice-president for engineering 3rd Nov. 2025

8

This hasn’t been my experience at all! So, that makes me curious. What race conditions and resource locks have you come across, and how do the three package managers affect each other? As far as I have understood, they are genuinely independent of each other.

9

This is an Ubuntu discussion, bringing up RPM is unrelated to the architecture being discussed.

On resource locking: the absence of personal experience does not invalidate a systemic issue. Lock contention between dpkg / APT and background services like snapd is a well-known behavior in Debian-based systems. It is reproducible under load and during concurrent package operations.

The problem is not whether a single user encounters it, but that multiple package managers operate without a unified transaction layer:

dpkg lock (/var/lib/dpkg/lock-frontend)

snapd’s independent update cycle

optional Flatpak transactions

These are separate state machines with no global orchestration, which leads to contention, delays, and degraded UX.

Regarding Jon Seager’s statements: internal plans are not equivalent to solved problems. Fragmentation remains observable in real-world usage.

Technical evidence is not anecdotal—it is visible at scale. The volume of “Could not get lock /var/lib/dpkg/lock-frontend” cases across support channels reflects a recurring architectural limitation, not isolated user error.

1 Like
10

The fact that they are ‘independent’ is exactly the architectural flaw. They are independent processes fighting for the same finite system resources (I/O, CPU, and D-Bus signaling) without a shared orchestration layer.

Example of a Race Condition: When snapd triggers an automatic refresh in the background while a user initiates a DPKG-based transaction. Because there is no cross-format lock coordination, the UI frontends (like App Center) often hang or report conflicting status because they can’t handle simultaneous state changes from different backends.

Example of Resource Lock: Try running a full system update while a background Snap refresh is pulling a heavy ‘gnome-platform’ update. You will face I/O saturation and D-Bus timeouts. Just because you haven’t seen the ‘lock-frontend’ error doesn’t mean the collision isn’t happening at the system level. A ‘Unified Backend’ would serialize these tasks, ensuring that ‘independent’ doesn’t mean ‘uncoordinated’.

2 Likes
11

I just want all packages available in one place, simple tools for maintenance, cleaning up residual configs, clean up snaps, etc.

1 Like
12

Exactly. Your point highlights why the current technical ‘independence’ of Snap, DEB, and Flatpak is a failure in terms of UX. Users shouldn’t need to be system administrators just to clean up residual configs or manage updates.

A Unified Backend isn’t just a ‘cool’ technical idea—it’s about fixing the mess so that users get that ‘one place’ for maintenance without resource collisions.

1 Like
13

@marcelstevano I agree your points about race conditions and lockouts having experienced them myself on more than one occasion. Your solution of a unified approach sounds attractive, but only as long as the experienced user is still able to individually control which repository from which they can choose.if they want.

Linux is all about choice, and choice should not be sacrificed on the altar of ease of use.

Cheers Tony

14

There are also functional package managers like guix and nix. They can run their own linux based OS (e.g., “guix system”) or on “foreign” distros (like Ubuntu). I use guix on Ubuntu. One advantage is that packages can be installed w/o sudo. Multiple versions of packages live together on the same system easily.

15

I’ve spent the last year contributing to KDE’s Discover to help improve the Snap backend, and while I have a great deal of respect for the work being done there, my experience has led me to a different perspective on the best way forward.

The Challenge of Unified Metadata

While PackageKit and AppStream work beautifully for Flatpaks and Debs, Snaps often operate under a different philosophy. Forcing a “one-size-fits-all” metadata standard can lead to technical friction because:

  • Structural Differences: A single Snap can contain multiple executables or desktop apps, which current GUI storefronts struggle to display or manage individually.

  • Format Flexibility: Snaps are frequently used for CLI tools. A standard “Open” button doesn’t translate well to a terminal-based application, creating a confusing experience for the user.

Support for the Current Direction

I actually find the approach taken by the App Center team to be quite sensible and well-considered. It respects the unique nature of the formats it handles.

However, my only point of polite disagreement is the decision to limit GUI updates strictly to Snaps. While I understand the desire for a curated experience, I believe providing a functional, reasonable GUI for all updates is more helpful to the end-user than omitting them entirely.

2 Likes