Replace APT with snap as default package manager

Registered by Kenny Strawn

Although APT has multiple front-ends, it like most package management systems dating to the early 2000s can be a pain to configure at times. Before there was snap and other tools (especially AppImages which are by far the cleanest solution available) that allowed apps to be self-contained, we had to deal with the problems that are PPAs ― and massive dependency problems in the event that a vendor decided to bypass the repositories altogether and distribute a standalone package.

Thanks to Snap, the need for APT is disappearing, fast. Apps ranging from browsers (Firefox, Chromium) all the way to complex developer tools (Android Studio) are available as these self-contained snap packages, so why don't we use snap at the system level?

Imagine, for example, being able to run "sudo snap install cosmic" to upgrade to the current release, "sudo snap install --beta disco" (in March) to upgrade to a beta release, or, for that matter, "sudo snap install --edge disco" to upgrade to a pre-beta release. It would make the whole process much easier, and updates could simply be delivered as updates to the corresponding snap, which could then just be pushed to the repositories and there it is. This way, instead of having a separate release updater, it would be possible to A, run all system updates completely and silently in the background to avoid nagging the user (a la Chrome OS), and B, offer release upgrades in the GNOME software store, Mac-style, as banners, so the user can install them easily. It would make the user experience both more consistent and even more user-friendly than it currently is.

Giving developers an easy path to migrate apps over to snaps (and encouraging the community to build snaps for OSS that isn't yet available as them, e.g. Qt Creator) would definitely be a must, however, before this is implemented.

Blueprint information

Not started
Mark Shuttleworth
Kenny Strawn
Needs approval
Mark Shuttleworth
Series goal:
Milestone target:

Related branches



What are those alleged "multiple fantastic front-ends" to APT ? I am aware of inadequate ones only. For example, debtags not fully supported and too few debtags carry meaningful info anyhow. Finding stuff is pure coincidence, package manager usually are hardly helpful there.


Work Items

This blueprint contains Public information 
Everyone can see this information.