Package Management Basics

apt, snap, flatpak, and .deb files — when to use each one, and how to install, update, and remove packages on Ubuntu-based systems.

Beginner Updated 14 min read Tested on Zorin OS 18.1 Pro (Ubuntu 24.04 Noble base) Hardware Lenovo ThinkPad L14 Gen 2

What This Guide Achieves

GoalStatus
Understand every way to install software on Ubuntu-based LinuxDone
Know which method to use for any given appDone
Learn the essential apt commands for daily useDone
Install, update, and uninstall software cleanlyDone
Avoid common package management pitfallsDone

Prerequisites

  • Any Ubuntu 24.04-based distro
  • Terminal access (Ctrl+Alt+T)
  • Admin (sudo) access

The Problem (Windows User Perspective)

On Windows, installing software is simple: you download an .exe from a website and double-click it. Maybe you use the Microsoft Store, but that’s about it. On Linux, there are five or more different ways to install software: apt, snap, flatpak, .deb files, AppImage, and building from source. Each method has trade-offs in speed, disk usage, security, and how well it integrates with your system.

This guide explains every method, when to use each one, and how they compare — so you never have to wonder “how do I install this?” again.

Clean Installation and Removal Best Practices

Use this checklist before installing or removing software. It keeps your system understandable, reversible, and easier to troubleshoot.

Before Installing

  • Prefer the distro repository first when the version is good enough.
  • Use the vendor’s official .deb, Snap, Flatpak, or repository only when you need that specific upstream version.
  • Avoid random one-line install scripts unless you trust the project and have inspected what the script changes.
  • For local .deb files, use sudo apt install ./package.deb so dependencies are handled cleanly.
  • Keep downloaded installers in ~/Downloads or another known location until you confirm the app works.
  • If an installer adds an APT repository, remember it adds a long-term update source, not just one app.

Before Removing

  • Remove only the app you installed, not broad dependency groups you do not understand.
  • Use apt remove when you may want to keep app settings.
  • Use apt remove --purge only when you intentionally want to remove package configuration too.
  • Run sudo apt autoremove --dry-run before a real autoremove when important desktop or development packages are involved.
  • Remove third-party repository files only when you are sure no other installed app depends on that repository.
  • Remove user data such as ~/.config/app-name only when you are sure you do not need saved settings, profiles, history, or projects.

Clean Control Rule

Install from one source, update from that same source, and uninstall using that source’s matching removal method. Mixing apt, Snap, Flatpak, AppImage, source builds, and installer scripts for the same app is the fastest way to lose track of what owns the files.

The Five Package Managers (and Two More)

1. apt (Advanced Package Tool)

The default, native package manager on Ubuntu-based systems. This is your primary tool for installing software. Think of it like a command-line app store that pulls software from official Ubuntu-based repositories.

Essential Commands

# Refresh package lists (like checking for updates — always run this first)
sudo apt update

# Install all available updates
sudo apt upgrade -y

# Install a package
sudo apt install package-name

# Install multiple packages at once
sudo apt install package1 package2 package3

# Remove a package (keeps config files)
sudo apt remove package-name

# Remove a package AND its config files
sudo apt remove --purge package-name

# Remove unused dependencies (packages installed as deps that are no longer needed)
sudo apt autoremove

# Search for packages by keyword
apt search keyword

# List all installed packages
apt list --installed

# Check if a specific package is installed
dpkg -l | grep package-name

# Show details about a package (version, description, dependencies)
apt show package-name

# Fix broken dependencies
sudo apt --fix-broken install

Adding PPAs (Personal Package Archives)

PPAs are third-party repositories hosted on Launchpad. They let you get newer versions of software or packages not in the official repos.

# Add a PPA
sudo add-apt-repository ppa:name/repo
sudo apt update

# Remove a PPA
sudo add-apt-repository --remove ppa:name/repo
sudo apt update

Example: Getting a newer version of TeXstudio:

sudo add-apt-repository ppa:sunderme/texstudio
sudo apt update
sudo apt install texstudio

When to Use apt

  • Best for: System packages, drivers, libraries, development tools, most software
  • Pros: Fastest install and launch times, smallest disk usage, best system integration, automatic dependency resolution
  • Cons: Package versions may lag behind the latest upstream releases (Ubuntu repos are updated on a fixed schedule)

2. Snap (Canonical’s Containerized Packages)

Snap packages are containerized — they bundle the app and all its dependencies into a single package that runs in a sandbox. Canonical (the company behind Ubuntu) maintains the Snap Store.

Essential Commands

# Install a snap
sudo snap install package-name

# Install a snap with classic confinement (full system access)
sudo snap install package-name --classic

# Remove a snap
sudo snap remove package-name

# List installed snaps
snap list

# Search for snaps
snap find keyword

# Update all snaps (happens automatically, but you can force it)
sudo snap refresh

# Show info about a snap
snap info package-name

When to Use Snap

  • Best for: Apps that need the latest version, apps that auto-update, proprietary apps (Spotify, Slack, Discord)
  • Pros: Always up-to-date, sandboxed for security, automatic updates
  • Cons: Slower startup on first launch (cold start), larger disk usage (~2-5x vs apt), creates loop devices in lsblk output, some apps have sandbox permission issues

Note: On Ubuntu-based desktops, the graphical software store often surfaces apps from multiple sources (apt, snap, and flatpak) behind the scenes. A GUI install may not give you the package format you expected — use the terminal to be explicit about which source you want.

3. Flatpak (via Flathub)

Flatpak is similar to Snap but is community-driven rather than Canonical-controlled. Flathub is the main repository for Flatpak apps. Some Ubuntu-based distros ship Flatpak support pre-configured; on others you may need to add it yourself.

Essential Commands

# Install from Flathub
flatpak install flathub app.name

# Example: install GIMP
flatpak install flathub org.gimp.GIMP

# Remove a flatpak
flatpak uninstall app.name

# List installed flatpaks
flatpak list

# Update all flatpaks
flatpak update

# Search for flatpaks
flatpak search keyword

# Run a flatpak app
flatpak run app.name

When to Use Flatpak

  • Best for: Desktop apps, especially when you want a newer version than apt provides
  • Pros: Sandboxed for security, large app selection on Flathub, distro-independent
  • Cons: Larger disk usage (shares runtimes between apps to save space, but still larger than apt), some apps have file access permission issues (sandboxing can block access to certain directories)

Flathub (https://flathub.org) is the main repository — you can browse it in your web browser to see what’s available.

4. .deb Files (Direct Download from Vendor)

.deb files are the Linux equivalent of Windows .exe installers for Debian/Ubuntu-based systems. Major software vendors (Google, Microsoft, Zoom) provide official .deb downloads on their websites.

How to Install

# Download the .deb file from the vendor's website, then:
sudo apt install ./package.deb

Always use sudo apt install ./ instead of sudo dpkg -i:

# CORRECT — resolves dependencies automatically
sudo apt install ./google-chrome-stable_current_amd64.deb

# AVOID — does NOT resolve dependencies, may leave your system in a broken state
sudo dpkg -i google-chrome-stable_current_amd64.deb

The ./ prefix tells apt to install from a local file rather than searching the repositories. It will automatically download and install any missing dependencies.

When to Use .deb Files

  • Best for: Chrome, Zoom, Discord, VS Code, and other apps where the vendor provides an official .deb download
  • Pros: Native performance, vendor-maintained, many vendors auto-add their apt repository for future updates
  • Cons: No auto-updates unless the vendor adds their own apt repository during installation (Chrome and VS Code do this; others may not)

5. AppImage (Portable, No Install Needed)

AppImage files are self-contained executables — like portable .exe files on Windows. No installation, no root access needed. Just download, make executable, and run.

How to Use

# Download the AppImage file from the app's website, then:

# Make it executable
chmod +x ./SomeApp.AppImage

# Run it
./SomeApp.AppImage

You can store AppImages anywhere — a common convention is ~/Applications/:

mkdir -p ~/Applications
mv SomeApp.AppImage ~/Applications/

When to Use AppImage

  • Best for: Trying out software without installing it, portable apps, apps not available through other methods
  • Pros: No installation required, no root access needed, no system modifications, easy to remove (just delete the file)
  • Cons: No auto-updates, no system integration by default (no menu entry, no file associations), each AppImage bundles its own dependencies (large file sizes)

6. Building from Source (git clone + make/cmake)

Only use this when no other option exists. Building from source means downloading the app’s source code and compiling it yourself.

Typical Process

# Install build tools (one-time setup)
sudo apt install build-essential cmake git

# Clone the source code
git clone https://github.com/developer/app-name.git
cd app-name

# Build (varies by project — check the project's README)
mkdir build && cd build
cmake ..
make

# Install (typically goes to /usr/local/bin/)
sudo make install

Real-World Example

RcloneBrowser had to be built from source because the AppImage download link on the project’s GitHub page was broken. The build process required installing Qt5 development libraries, cloning the repo, running cmake, and compiling — about 15 minutes of work vs. 30 seconds for an apt install.

When to Build from Source

  • Best for: Bleeding-edge versions, niche software, apps with broken binary releases
  • Cons: No package manager tracks it (no auto-updates, no clean removal), manual update process, may leave build artifacts scattered across your system, requires development tools to be installed, build can fail due to missing dependencies

Decision Flowchart: Which Method to Use

When you need to install software, follow this order:

1. Check apt first
   └─ sudo apt search app-name
   └─ If found and version is acceptable → sudo apt install app-name
   └─ DONE

2. If not in apt or version is too old → check Flathub
   └─ flatpak search app-name
   └─ Or browse https://flathub.org
   └─ If found → flatpak install flathub app.name
   └─ DONE

3. If vendor provides official .deb download → use that
   └─ Check the app's official website for a Linux/.deb download
   └─ Common: Chrome, Zoom, Discord, VS Code, Slack
   └─ sudo apt install ./downloaded-package.deb
   └─ DONE

4. Use snap when it's the only or easiest option
   └─ snap find app-name
   └─ sudo snap install app-name
   └─ DONE

5. AppImage for portable or trial apps
   └─ Download .AppImage from the project's website
   └─ chmod +x ./App.AppImage && ./App.AppImage
   └─ DONE

6. Build from source as absolute last resort
   └─ git clone, cmake, make, sudo make install
   └─ DONE

Quick Reference: Method Comparison

MethodSpeedDisk UsageAuto-UpdatesSystem IntegrationSandboxed
aptFastestSmallestYes (via apt upgrade)FullNo
snapSlow cold startLargeYes (automatic)GoodYes
flatpakModerateLargeYes (via flatpak update)GoodYes
.debFastSmallDepends on vendorFullNo
AppImageFastLarge per-appNoNone by defaultNo
SourceN/AVariesNoMinimalNo

Common Issues and Solutions

Duplicate Repository Entries (.list vs .sources)

When you install Chrome or Edge, the installer may create two repository files — an old-format .list file and a new-format .sources file — causing duplicate entry errors during apt update.

Diagnosis:

ls /etc/apt/sources.list.d/ | grep google
# If you see both google-chrome.list AND google-chrome.sources, you have duplicates

Fix: Remove the old .list file and keep the modern .sources file:

sudo rm /etc/apt/sources.list.d/google-chrome.list
sudo apt update

See Browser Setup Guide for detailed instructions.

GPG Key Errors When Adding PPAs

The following signatures couldn't be verified: NO_PUBKEY XXXXXXXXXXXXXXXX

Fix for Ubuntu 24.04-based systems:

# Import the repository key into a dedicated keyring file
wget -qO- https://example.com/key.asc | sudo gpg --dearmor -o /usr/share/keyrings/example.gpg

# Then make sure the repository entry uses signed-by=
echo "deb [signed-by=/usr/share/keyrings/example.gpg] https://example.com/repo stable main" | sudo tee /etc/apt/sources.list.d/example.list

sudo apt update

Replace the example URL, key file name, and repo line with the values from the vendor or PPA instructions you are actually using. Old tutorials that suggest apt-key adv are outdated for modern Ubuntu-based systems.

dpkg -i vs apt install ./ — Always Prefer apt

# This can break your system:
sudo dpkg -i package.deb
# If dependencies are missing, you'll get errors and a half-installed package

# Fix a broken dpkg install:
sudo apt --fix-broken install

# This is the correct way:
sudo apt install ./package.deb
# apt handles dependencies automatically

The —no-autoremove Flag

When removing a small package that was pulled in by a large meta-package (like removing prerex from texlive-full), a plain apt remove will try to auto-remove the entire dependency chain:

# DANGEROUS — may try to remove 194+ packages:
sudo apt remove prerex

# SAFE — only removes prerex, leaves everything else intact:
sudo apt remove --no-autoremove prerex

See TeX Live and TeXstudio Guide for a real-world example.

Preventing Auto-Removal of Important Packages

If sudo apt autoremove lists packages you want to keep, mark them as manually installed:

# Mark a package as manually installed (prevents auto-removal)
sudo apt-mark manual package-name

# Check what autoremove would do (dry run — no changes made)
sudo apt autoremove --dry-run

# Example: protect TeX Live after removing extras
sudo apt-mark manual texlive-full

What Didn’t Work (and Why)

Approach TriedWhy It Failed
Using sudo dpkg -i package.deb instead of sudo apt install ./package.debdpkg does not resolve dependencies — if the package needs libraries you don’t have, the install fails and leaves the package half-configured
Having both .list and .sources files for the same repository (Chrome, Edge)Creates duplicate entry errors during apt update — the system tries to fetch the same packages from two conflicting sources
Removing packages from texlive-full without --no-autoremoveapt treated the remaining 194 TeX Live packages as orphaned dependencies and tried to remove them all (4.5 GB)
Downloading .exe files from Windows download pagesLinux cannot run .exe files natively — you need the .deb package or use the appropriate package manager
Using the RcloneBrowser AppImage link from GitHubThe download link was broken/outdated — had to build from source instead

Verification

# Check apt is working
sudo apt update

# List installed apt packages
apt list --installed | wc -l

# List installed snaps
snap list

# List installed flatpaks
flatpak list

# Check for broken packages
sudo apt --fix-broken install

Discussion