Name	Name	Last commit message	Last commit date
parent directory ..
AUR_INSTALLATION.md	AUR_INSTALLATION.md
FLATPAK_SANDBOXING.md	FLATPAK_SANDBOXING.md
README.md	README.md
WM.md	WM.md

Linux Package Management & Installation

Complete guide to installing and managing applications on Arch-based systems, covering AppImage, Flatpak, AUR packages, and common installation issues.

This document explains:

Which Linux package format to choose (AppImage, Flatpak, .deb)
How to run AppImages on Arch-based systems
How to properly integrate applications into KDE Application Launcher
Common Flatpak sandboxing issues and solutions

Related guides:

AUR Package Installation - Building and maintaining packages from the Arch User Repository
Flatpak Sandboxing Issues - Troubleshooting browser settings and data persistence

It is written for:

Arch Linux & Arch-based distros (CachyOS, EndeavourOS, etc.)
KDE Plasma desktop
Users downloading apps that offer .AppImage, .deb, or Flatpak formats

Choosing the Correct Package Format

What Are Package Formats?

Definition: Package formats are different ways applications are distributed and installed on Linux systems.

Why multiple formats exist:

Different distros: Each distro has its own package system
Different needs: Users have different requirements (portability, updates, security)
Developer choice: Developers choose format based on their needs

Common formats:

.deb: Debian/Ubuntu package format
.rpm: Red Hat/Fedora package format
AppImage: Portable, distro-agnostic format
Flatpak: Sandboxed, universal format
Snap: Canonical's universal format

Real-world analogy:

Package formats = Different languages (each distro speaks different language)
AppImage = Universal translator (works everywhere)
Flatpak = Standardized language (works across distros with runtime)

flowchart TD
    Start([Need Linux App]) --> Format{Available Formats?}

    Format -->|AppImage & .deb| CheckArch{Arch-based<br/>System?}
    CheckArch -->|Yes| ChooseAppImage[✅ Use AppImage<br/>Distro-agnostic]
    CheckArch -->|No| CheckDeb{Debian/Ubuntu?}
    CheckDeb -->|Yes| UseDeb[Use .deb]
    CheckDeb -->|No| ChooseAppImage

    Format -->|AppImage & Flatpak| CheckNeeds{Need Portable<br/>or Auto-updates?}
    CheckNeeds -->|Portable| ChooseAppImage
    CheckNeeds -->|Auto-updates| UseFlatpak[Use Flatpak<br/>Centralized updates]

    Format -->|Only AppImage| ChooseAppImage
    Format -->|Only .deb| Warn[⚠️ Not Recommended<br/>on Arch]

    ChooseAppImage --> End([Download AppImage])
    UseDeb --> End
    UseFlatpak --> End
    Warn --> End

    style Start fill:#e1f5ff
    style ChooseAppImage fill:#4caf50,color:#fff
    style UseFlatpak fill:#2196f3,color:#fff
    style Warn fill:#f44336,color:#fff
    style End fill:#c8e6c9

Decision Flow Explained

If an application provides the following options:

Linux (.AppImage)
Linux (.deb)

✅ Recommended: AppImage

Do not use .deb on Arch-based systems.

Why not .deb:

1. .deb is for Debian/Ubuntu (apt):

What .deb is: Debian package format, used by Debian/Ubuntu
Package manager: Uses apt (Advanced Package Tool)
Arch doesn't use: Arch uses pacman, not apt
Incompatible: .deb packages don't work natively on Arch

2. Arch uses pacman and does not support .deb natively:

Arch package manager: pacman (Package Manager)
Different format: Arch uses its own package format
No native support: Can't install .deb directly with pacman
Requires conversion: Would need to convert .deb to Arch format

3. Converting .deb packages is fragile and error-prone:

Conversion tools: Tools like debtap exist but are unreliable
Dependency issues: Dependencies may not match Arch packages
Breaking risk: Can break system or cause conflicts
Not recommended: Better to use AppImage instead

Real-world example:

Trying to use .deb on Arch:

# This won't work:
sudo pacman -U package.deb
# Error: pacman doesn't support .deb files

# Conversion attempt:
debtap package.deb
# May work, but dependencies may be wrong
# Can cause system conflicts

Using AppImage instead:

# This works:
chmod +x package.AppImage
./package.AppImage
# Works immediately, no conversion needed ✅

Why AppImage Works Well on Arch

1. Distro-agnostic:

What it means: Works on any Linux distribution
Why it works: Bundles all dependencies, doesn't rely on system packages
Benefit: Same AppImage works on Arch, Ubuntu, Fedora, etc.

2. Bundles its own dependencies:

What it means: AppImage includes all libraries it needs
Why it works: Doesn't depend on system-installed libraries
Benefit: No dependency conflicts, works regardless of system state

3. No system installation required:

What it means: Just download and run, no sudo needed
Why it works: Runs from user directory, doesn't modify system
Benefit: Safe, doesn't affect system packages

4. Works reliably on rolling-release systems:

What rolling-release means: System packages update continuously (like Arch)
Why AppImage helps: Doesn't depend on system packages, so updates don't break it
Benefit: Stable even as system packages change

Real-world example:

Arch system with AppImage:

System packages update frequently (rolling release)
AppImage doesn't depend on system packages
AppImage continues working even as system updates
No conflicts or breakage ✅

Arch system with .deb (converted):

System packages update frequently
Converted package depends on specific system packages
System updates may break converted package
Dependency conflicts possible ❌

Running an AppImage on Arch

flowchart LR
    A[Download AppImage] --> B[Make Executable<br/>chmod +x]
    B --> C{Has FUSE2?}
    C -->|No| D[Install fuse2<br/>pacman -S fuse2]
    C -->|Yes| E[Run AppImage]
    D --> E
    E --> F{Works?}
    F -->|No| G[Troubleshoot]
    F -->|Yes| H[Move to ~/.local/bin]
    H --> I[Create Desktop Entry]
    I --> J[Extract Icon]
    J --> K[Refresh KDE Cache]
    K --> L[✅ Complete]

    style A fill:#e1f5ff
    style D fill:#fff3e0
    style E fill:#e8f5e9
    style L fill:#4caf50,color:#fff

Step 1: Make the AppImage executable

From a terminal:

chmod +x MyApp-x86_64.AppImage

Or via KDE:

Right-click → Properties → Permissions
Enable "Is executable"

Step 2: Install required dependency (FUSE)

Many AppImages require FUSE v2, which is not installed by default on Arch.

Install it once:

sudo pacman -S fuse2

Without this, AppImages may silently fail when launched.

Step 3: Run the AppImage

./MyApp-x86_64.AppImage

If it launches successfully, the AppImage itself is working correctly.

Running Applications in Background and Detaching from Terminal

What process detachment means: Running applications or commands in a way that they continue running even after you close the terminal, log out, or disconnect from SSH.

Why this matters for package management:

Long-running installations: Package installations that take time
AppImage updates: Updating AppImages in the background
Flatpak operations: Long-running Flatpak installs or updates
Background services: Applications that should run continuously

Real-world scenarios:

Installing large Flatpak applications
Running AppImages that perform long operations
Updating multiple packages
Running applications that should survive terminal closure

Background Execution with `&`

Basic background execution:

# Run AppImage in background
~/.local/bin/myapp &

# Run Flatpak install in background
flatpak install flathub org.gimp.GIMP &

# Run package update in background
paru -Syu &

What this does:

&: Runs command in background
Terminal free: You can continue using terminal
Output visible: Output still appears in terminal
⚠️ Limitation: Process terminates when terminal closes

Real-world example:

# Start AppImage in background
~/.local/bin/myapp &

# Terminal returns immediately
# You can run other commands
# But closing terminal kills the app ❌

Detaching Processes: `disown`

What disown does: Removes a job from the shell's job table, preventing SIGHUP from being sent when terminal closes.

Basic usage:

# Start and immediately detach
~/.local/bin/myapp & disown

# Or detach existing background job
~/.local/bin/myapp &
disown %1  # Disown job number 1
disown $!  # Disown last background process

What this does:

&: Starts process in background
disown: Removes from shell's job table
Result: Process survives terminal closure ✅

Real-world example:

# Start AppImage, detach from terminal
~/.local/bin/myapp & disown

# Close terminal - app continues running ✅

With output redirection:

# Detach and redirect output to log file
~/.local/bin/myapp > app.log 2>&1 & disown

# Output goes to app.log, not terminal
# Process survives terminal closure

Using `nohup` for Long-Running Tasks

What nohup does: Runs a command immune to "hangup" signals (SIGHUP), automatically redirecting output to nohup.out.

Basic usage:

# Run with nohup
nohup ~/.local/bin/myapp &

# Output goes to nohup.out

Custom output file:

# Redirect to custom file
nohup ~/.local/bin/myapp > app.log 2>&1 &

# Both stdout and stderr to file

Real-world examples:

Long-running Flatpak installation:

# Install large Flatpak app, survive terminal closure
nohup flatpak install flathub org.gimp.GIMP > install.log 2>&1 & disown

# Close terminal - installation continues ✅
# Check progress: tail -f install.log

AppImage update:

# Update AppImage in background
nohup appimageupdate ~/.local/bin/myapp > update.log 2>&1 & disown

# Close terminal - update continues ✅

Package updates:

# System update in background
nohup paru -Syu > update.log 2>&1 & disown

# Close terminal - update continues ✅
# Check progress: tail -f update.log

Using `setsid` for Complete Detachment

What setsid does: Runs a command in a new session, completely detached from the controlling terminal.

Basic usage:

# Run in new session
setsid ~/.local/bin/myapp

# With output redirection
setsid ~/.local/bin/myapp > app.log 2>&1

Real-world example:

# Start AppImage in new session
setsid ~/.local/bin/myapp > app.log 2>&1 &

# Completely detached from terminal ✅

Comparison Table

Method	Survives Terminal Close	Output Handling	Best For
`&` alone	❌ No	Terminal	Short background tasks
`& disown`	✅ Yes	Terminal (unless redirected)	Quick detachment
`nohup ... &`	✅ Yes	`nohup.out` (or custom)	Long-running tasks
`setsid`	✅ Yes	Must redirect manually	Complete detachment
`nohup ... & disown`	✅✅ Yes (double protection)	Custom file	Critical processes

Best Practices for Package Management

1. Always redirect output for long operations:

# Good: Redirect output
nohup flatpak install flathub org.gimp.GIMP > install.log 2>&1 & disown

# Bad: Output goes to terminal
flatpak install flathub org.gimp.GIMP & disown

2. Use nohup for installations and updates:

# Good: Use nohup for long operations
nohup paru -Syu > update.log 2>&1 & disown

# Less ideal: Just & disown
paru -Syu & disown

3. Track PIDs for monitoring:

# Good: Save PID for later reference
nohup flatpak install flathub org.gimp.GIMP > install.log 2>&1 &
PID=$!
disown $PID
echo $PID > install.pid

# Later: check if still running
if ps -p $(cat install.pid) > /dev/null; then
    echo "Installation still running"
else
    echo "Installation completed"
fi

4. Use setsid for services:

# Good: Complete detachment for services
setsid ~/.local/bin/myapp </dev/null >app.log 2>&1 &

5. Combine methods for critical operations:

# Good: Maximum protection
setsid nohup flatpak install flathub org.gimp.GIMP > install.log 2>&1 & disown

Real-World Examples

Example 1: Detached AppImage Launch

# Start AppImage, survive terminal closure
nohup ~/.local/bin/myapp > app.log 2>&1 & disown

# Close terminal - app continues running ✅
# Check logs: tail -f app.log

Example 2: Background Flatpak Installation

# Install large Flatpak app in background
nohup flatpak install flathub org.gimp.GIMP > install.log 2>&1 & disown

# Close terminal - installation continues ✅
# Monitor: tail -f install.log

Example 3: Multiple Package Updates

# Update multiple packages, survive terminal closure
nohup paru -S package1 package2 package3 > updates.log 2>&1 & disown

# Close terminal - updates continue ✅

Example 4: AppImage Update with Monitoring

# Update AppImage, track progress
nohup appimageupdate ~/.local/bin/myapp > update.log 2>&1 &
UPDATE_PID=$!
disown $UPDATE_PID

echo "Update started with PID: $UPDATE_PID"
echo $UPDATE_PID > update.pid

# Monitor: tail -f update.log
# Check status: ps -p $(cat update.pid)

Example 5: Silent Background Service

# Start AppImage as background service
setsid ~/.local/bin/myapp </dev/null >app.log 2>&1 &

# Completely silent, detached service ✅

Troubleshooting

Problem: Process still dies after terminal closure

Solutions:

Use disown: command & disown
Use nohup: nohup command &
Use setsid: setsid command &
Combine methods: nohup command & disown

Problem: Output still appears in terminal

Solutions:

Redirect to file: command > output.log 2>&1 & disown
Redirect to /dev/null: command </dev/null >/dev/null 2>&1 & disown
Use nohup: Automatically redirects to nohup.out

Problem: Can't check if process completed

Solutions:

Save PID: command & PID=$!; disown $PID; echo $PID > process.pid
Check logs: tail -f output.log
Check process: ps -p $(cat process.pid)

Related Commands

jobs: List background jobs (won't show disowned jobs)
fg: Bring job to foreground (won't work for disowned jobs)
bg: Resume stopped job in background
screen: Terminal multiplexer for detachable sessions
tmux: Terminal multiplexer alternative

Learn more:

Process management: See ../shell-commands/02-commands/ps.md
Process detachment: See ../shell-commands/03-combinations/chaining.md#process-detachment-keeping-processes-running-after-terminal-closes

Placing the AppImage in a Stable Location

Do not leave AppImages in the Downloads directory.

Recommended location:

mkdir -p ~/.local/bin
mv MyApp-x86_64.AppImage ~/.local/bin/myapp
chmod +x ~/.local/bin/myapp

This ensures:

Stable paths
No accidental deletion
Cleaner desktop integration

Adding the AppImage to KDE Application Launcher

AppImages do not automatically appear in the app menu. To integrate them properly, create a .desktop file.

Step 1: Create the applications directory (if missing)

mkdir -p ~/.local/share/applications

Step 2: Create a desktop entry

Create a file named myapp.desktop:

nano ~/.local/share/applications/myapp.desktop

Paste the following (generic template):

[Desktop Entry]
Type=Application
Name=MyApp
Comment=Application Description
Exec=/home/USER/.local/bin/myapp
Icon=utilities-terminal
Terminal=false
Categories=Development;Utility;

⚠️ Replace:

/home/USER with your actual home path
myapp with the AppImage filename

Step 3: Refresh KDE application cache

kbuildsycoca6

The application will now appear in:

KDE Application Launcher
Search
Favorites / Task Manager (if pinned)

Icon Extraction & Theming

By default, desktop entries use generic icons (like utilities-terminal). To use the actual application icon from the AppImage, extract it and reference it in your .desktop file.

Step 1: Extract the AppImage

AppImages are self-extracting archives. Extract the contents temporarily:

cd ~/.local/bin
./myapp --appimage-extract

This creates a squashfs-root/ directory containing the AppImage's internal structure.

Step 2: Find the icon

Icons are typically located in:

# Common locations to check:
ls squashfs-root/*.png
ls squashfs-root/*.svg
ls squashfs-root/*.ico
ls squashfs-root/usr/share/pixmaps/
ls squashfs-root/usr/share/icons/
ls squashfs-root/.DirIcon  # AppImage standard icon

The .DirIcon file is the AppImage's standard icon (usually a PNG or SVG).

Step 3: Copy icon to user directory

Create icons directory and copy the icon:

# Create icons directory
mkdir -p ~/.local/share/icons/hicolor/256x256/apps

# Copy icon (adjust path as needed)
cp squashfs-root/.DirIcon ~/.local/share/icons/hicolor/256x256/apps/myapp.png

# Or if using a different icon file:
cp squashfs-root/usr/share/pixmaps/myapp.png ~/.local/share/icons/hicolor/256x256/apps/myapp.png

For SVG icons:

mkdir -p ~/.local/share/icons/hicolor/scalable/apps
cp squashfs-root/.DirIcon ~/.local/share/icons/hicolor/scalable/apps/myapp.svg

Step 4: Update desktop entry

Edit your .desktop file to reference the icon:

[Desktop Entry]
Type=Application
Name=MyApp
Comment=Application Description
Exec=/home/USER/.local/bin/myapp
Icon=myapp
Terminal=false
Categories=Development;Utility;

Or use the full path:

Icon=/home/USER/.local/share/icons/hicolor/256x256/apps/myapp.png

Step 5: Refresh icon cache

Update the icon cache so KDE recognizes the new icon:

# For KDE Plasma
kbuildsycoca6

# For GTK-based apps (optional)
gtk-update-icon-cache ~/.local/share/icons/hicolor/

Step 6: Clean up extraction

Remove the temporary extraction directory:

rm -rf ~/.local/bin/squashfs-root

Alternative: Using system icon themes

If you prefer to use system icons, you can reference them by name:

Icon=application-x-executable  # Generic executable icon
Icon=utilities-terminal        # Terminal icon
Icon=system-software-install   # Install icon

Browse available icons:

# KDE icon themes
ls /usr/share/icons/
ls ~/.local/share/icons/

AppImage Updates

flowchart TD
    Start([Check for Updates]) --> CheckMethod{Update Method?}

    CheckMethod -->|Manual| Manual[Manual Update]
    CheckMethod -->|AppImageUpdate| AutoUpdate[AppImageUpdate]
    CheckMethod -->|AppImageLauncher| Launcher[AppImageLauncher]

    Manual --> M1[Backup Current Version]
    M1 --> M2[Download New Version]
    M2 --> M3[Replace Old File]
    M3 --> M4[Test New Version]
    M4 --> M5{Works?}
    M5 -->|No| M6[Restore Backup]
    M5 -->|Yes| M7[✅ Updated]
    M6 --> M7

    AutoUpdate --> AU1[Check Update Info]
    AU1 --> AU2{Update Available?}
    AU2 -->|Yes| AU3[Run appimageupdate]
    AU2 -->|No| AU4[Already Latest]
    AU3 --> AU5[✅ Updated]

    Launcher --> L1[Download New Version]
    L1 --> L2[Launcher Detects]
    L2 --> L3[Prompt to Replace]
    L3 --> L4[✅ Updated]

    style Start fill:#e1f5ff
    style M7 fill:#4caf50,color:#fff
    style AU5 fill:#4caf50,color:#fff
    style L4 fill:#4caf50,color:#fff
    style AU4 fill:#fff3e0

AppImages do not update automatically. You need to manually download and replace the old version.

Manual Update Process

Step 1: Backup current version (recommended)

cd ~/.local/bin
cp myapp myapp.backup

This allows you to roll back if the new version has issues.

Step 2: Download new version

Download the new AppImage from the official source. Verify the filename matches your current one (or update your .desktop file if the name changed).

Step 3: Replace old version

# Stop the application if running
# Then replace:
mv ~/Downloads/MyApp-x86_64.AppImage ~/.local/bin/myapp
chmod +x ~/.local/bin/myapp

Note: If the application is running in the background or detached from terminal, you may need to stop it first:

# Find and stop running AppImage
pkill -f myapp

# Or if you saved the PID earlier:
kill $(cat app.pid)

Step 4: Test the new version

Launch the application to ensure it works correctly:

~/.local/bin/myapp

For long-running updates: If updating takes time, you can run the update in the background:

# Update AppImage in background, survive terminal closure
nohup appimageupdate ~/.local/bin/myapp > update.log 2>&1 & disown

# Monitor progress: tail -f update.log

If issues occur, restore the backup:

mv ~/.local/bin/myapp.backup ~/.local/bin/myapp

Using AppImageUpdate (if available)

Some AppImages support automatic updates via AppImageUpdate. Check if your AppImage supports it:

~/.local/bin/myapp --appimage-updateinfo

If update information is available, you can update:

# Install AppImageUpdate (AUR)
paru -S appimageupdate

# Update the AppImage
appimageupdate ~/.local/bin/myapp

Note: Not all AppImages provide update information. This method only works if the developer has configured it.

AppImageLauncher Update Integration

If you're using AppImageLauncher, it can help manage updates:

AppImageLauncher detects when you download a new version
It can prompt you to replace the old integrated version
Updates maintain your desktop integration automatically

Best Practices for Version Management

Keep backups: Always backup before updating
Check release notes: Review changelogs before updating
Test thoroughly: Verify the new version works with your workflow

Version naming: Some users keep multiple versions:

~/.local/bin/myapp-v1.0.0
~/.local/bin/myapp-v2.0.0

Update regularly: Check for updates monthly or when security issues are announced
Verify sources: Always download from official sources

Handling Multiple Versions

If you need to keep multiple versions:

# Install versions with version numbers
~/.local/bin/myapp-1.0.0
~/.local/bin/myapp-2.0.0

# Create separate desktop entries
~/.local/share/applications/myapp-1.0.0.desktop
~/.local/share/applications/myapp-2.0.0.desktop

Update the Exec= and Name= fields in each .desktop file accordingly.

Security Considerations

AppImages run with your user permissions and are not sandboxed by default. Follow these security best practices:

Verify AppImage Signatures

Some AppImages are cryptographically signed. Verify signatures when available:

# Check if AppImage is signed
~/.local/bin/myapp --appimage-signature

# Verify signature (requires GPG key)
gpg --verify myapp.AppImage.sig myapp.AppImage

Note: Most AppImages are not signed. This is a limitation of the current ecosystem.

Download from Trusted Sources

Official websites: Always download from the application's official website
GitHub Releases: Verify you're on the correct repository
Avoid third-party mirrors: Unless you trust the mirror operator
Check URLs: Verify download URLs match the official domain

Verify File Integrity

Check SHA256 checksums when provided:

# Download checksum file
wget https://example.com/myapp.AppImage.sha256

# Calculate checksum of downloaded file
sha256sum ~/Downloads/myapp.AppImage

# Compare with provided checksum
cat myapp.AppImage.sha256

If checksums don't match, do not run the AppImage.

Run with Appropriate Permissions

User-level execution: AppImages run as your user, not root
Avoid running as root: Never use sudo with AppImages unless absolutely necessary

Check file permissions: Ensure only you can execute:

ls -l ~/.local/bin/myapp
# Should show: -rwxr-xr-x (owner executable, others not)

Sandboxing Considerations

AppImages are not sandboxed by default. They have access to:

Your home directory
Network access
System resources (CPU, memory, GPU)
Other running applications

Considerations:

Firewall: Use a firewall to restrict network access if needed
AppArmor/SELinux: Can be configured to restrict AppImage behavior (advanced)
Isolated execution: Run in a VM or container for untrusted applications
Review permissions: Check what the application requests access to

AppImageLauncher Security Features

AppImageLauncher provides some security benefits:

Centralized management: All AppImages in one location (~/Applications/)
Verification prompts: Asks before integrating new AppImages
Isolation: Can help prevent accidental execution of malicious files

When to Be Cautious

Red flags:

Unsigned AppImages from unknown sources
AppImages downloaded from file-sharing sites
Checksums don't match
AppImages requesting root access unnecessarily
AppImages from unverified GitHub forks
AppImages with unusual file sizes (too small or suspiciously large)

Safe practices:

Research the application before downloading
Check GitHub stars, issues, and community activity
Read user reviews and forum discussions
Start with well-known applications
Use AppImageLauncher for better management

Reporting Security Issues

If you discover a security issue:

Do not run the AppImage
Report to the application maintainer
Report to security@lists.appimage.org if it's an AppImage format issue
Consider reporting to your distribution's security team

Flatpak vs AppImage Comparison

Both Flatpak and AppImage are modern Linux application distribution formats. Here's how they compare:

Distribution Model

Aspect	Flatpak	AppImage
Distribution	Centralized repositories (Flathub, etc.)	Direct download from developers
Discovery	Via software centers and `flatpak search`	Manual download from websites
Installation	`flatpak install app`	Download and make executable

Flatpak: Applications are distributed through repositories like Flathub, making discovery and installation easier.

AppImage: Applications are downloaded directly from developer websites or GitHub releases, giving developers full control.

Dependencies

Aspect	Flatpak	AppImage
Runtime	Shared runtimes (e.g., `org.freedesktop.Platform`)	Bundled with application
Size	Smaller per-app (shared dependencies)	Larger per-app (self-contained)
Updates	Runtime updates benefit all apps	Each app updates independently

Flatpak: Uses shared runtimes, reducing disk space. Multiple apps share the same runtime.

AppImage: Each AppImage bundles its dependencies, resulting in larger individual files but complete portability.

Updates

Aspect	Flatpak	AppImage
Method	`flatpak update` (automatic)	Manual download and replace
Frequency	Centralized, regular updates	Per-developer schedule
Ease	Single command updates all apps	Manual per-application

Flatpak: Updates are centralized and can be automated. One command updates all Flatpak applications.

AppImage: Updates require manually downloading new versions and replacing old ones. Some apps support AppImageUpdate, but it's not universal.

Size Comparison

Example: A text editor

Flatpak: ~50-100 MB (shares runtime with other apps)
AppImage: ~100-200 MB (includes all dependencies)

Total for 10 applications:

Flatpak: ~500 MB (shared runtime) + ~50 MB per app = ~1 GB
AppImage: ~100-200 MB per app = ~1-2 GB

Winner: Flatpak for multiple applications, AppImage for single portable apps.

Desktop Integration

Aspect	Flatpak	AppImage
Menu Integration	Automatic	Manual (`.desktop` files)
Icons	Automatic	Manual extraction
MIME Types	Automatic	Manual configuration
File Associations	Automatic	Manual setup

Flatpak: Full automatic integration with desktop environments.

AppImage: Requires manual setup of .desktop files and icons (or use AppImageLauncher).

Security & Sandboxing

Aspect	Flatpak	AppImage
Sandboxing	Yes (bubblewrap)	No (runs with user permissions)
Permissions	Granular control	Full user access
Isolation	Strong isolation	No isolation
Security Model	Restrictive by default	Permissive by default

Flatpak: Applications run in sandboxes with restricted access. Permissions can be managed via flatpak override.

AppImage: Runs with full user permissions, no sandboxing. You trust the application completely.

Use Cases: When to Choose Each

Choose Flatpak when:

You want automatic updates
You install many applications
You prefer centralized management
Security/sandboxing is important
You want easy discovery via software centers
You're okay with repository dependency

Choose AppImage when:

You need portable applications (USB drive, network share)
You want to run without installation
You prefer direct developer distribution
You need specific versions not in Flatpak repos
You want to test applications without system changes
You're on a system without Flatpak support

Arch-Specific Considerations

Both work well on Arch:

Flatpak: Available in official repos (pacman -S flatpak)
AppImage: Works out-of-the-box with fuse2 installed
Performance: Both perform well on Arch
Integration: Both integrate with KDE Plasma

Recommendation:

Use Flatpak for regularly-used applications that benefit from automatic updates
Use AppImage for portable tools, one-off applications, or when you need specific versions
Many users use both formats depending on the application

Hybrid Approach

You can use both formats simultaneously:

# Install common apps via Flatpak
flatpak install flathub org.gimp.GIMP
flatpak install flathub org.inkscape.Inkscape

# Use AppImage for portable tools
~/.local/bin/portable-tool.AppImage

This gives you the benefits of both: centralized management for common apps and portability for specialized tools.

AUR Package Installation

For software not available as AppImage or Flatpak, the Arch User Repository (AUR) provides community-maintained build scripts. This is the native Arch way to install third-party software.

When to use AUR:

Application only provides source code or AUR package
You need tight system integration
You prefer native packages over containerized formats
The software isn't available in other formats

Common AUR packages:

Application	AUR Package
Notion	`notion-app-electron`
Spotify	`spotify`
Discord	`discord`
Visual Studio Code	`visual-studio-code-bin`
Zoom	`zoom`

Quick install with paru:

paru -S package-name

Manual installation:

git clone https://aur.archlinux.org/package-name.git
cd package-name
makepkg -si

For a complete guide including security considerations, updating AUR packages, and troubleshooting, see AUR_INSTALLATION.md.

Optional: Automatic Integration with AppImageLauncher

If you use multiple AppImages, AppImageLauncher can automate menu integration.

Install (AUR)

Using an AUR helper:

paru -S appimagelauncher-bin

For long-running installations: If the installation takes time, you can run it in the background:

# Install in background, survive terminal closure
nohup paru -S appimagelauncher-bin > install.log 2>&1 & disown

# Monitor progress: tail -f install.log

Recommended choice:

appimagelauncher-bin → precompiled, stable, fastest install

What AppImageLauncher Does

Detects AppImages on first run
Offers "Integrate and run"
Automatically creates menu entries and icons
Moves AppImages to a managed location

This is optional but convenient.

Summary

Best Practices on Arch/KDE

Prefer AppImage over .deb
Install fuse2
Store AppImages in ~/.local/bin
Use .desktop files for menu integration
Extract and use application icons for better integration
Keep backups before updating AppImages
Verify checksums and download from trusted sources
Use AppImageLauncher if managing many AppImages
Consider Flatpak for applications that benefit from automatic updates
Use AUR for native Arch packages not in official repos (see AUR_INSTALLATION.md)

Mental Model

AppImage = portable executable
.desktop file = menu integration
FUSE = runtime requirement
Icon extraction = better visual integration
Manual updates = developer control
Security = user responsibility

Once set up, AppImages behave like native applications without touching system packages.

This README is suitable for:

Personal reference
Public repositories
New Linux users learning Arch/KDE workflows

FilesExpand file tree

linux-packages

Directory actions

More options

Directory actions

More options

Latest commit

History

linux-packages

Folders and files

parent directory

README.md

Linux Package Management & Installation

Choosing the Correct Package Format

What Are Package Formats?

Decision Flow Explained

✅ Recommended: AppImage

Why AppImage Works Well on Arch

Running an AppImage on Arch

Step 1: Make the AppImage executable

Step 2: Install required dependency (FUSE)

Step 3: Run the AppImage

Running Applications in Background and Detaching from Terminal

Background Execution with &

Detaching Processes: disown

Using nohup for Long-Running Tasks

Using setsid for Complete Detachment

Comparison Table

Best Practices for Package Management

Real-World Examples

Example 1: Detached AppImage Launch

Example 2: Background Flatpak Installation

Example 3: Multiple Package Updates

Example 4: AppImage Update with Monitoring

Example 5: Silent Background Service

Troubleshooting

Related Commands

Placing the AppImage in a Stable Location

Adding the AppImage to KDE Application Launcher

Step 1: Create the applications directory (if missing)

Step 2: Create a desktop entry

Step 3: Refresh KDE application cache

Icon Extraction & Theming

Step 1: Extract the AppImage

Step 2: Find the icon

Step 3: Copy icon to user directory

Step 4: Update desktop entry

Step 5: Refresh icon cache

Step 6: Clean up extraction

Alternative: Using system icon themes

AppImage Updates

Manual Update Process

Step 1: Backup current version (recommended)

Step 2: Download new version

Step 3: Replace old version

Step 4: Test the new version

Using AppImageUpdate (if available)

AppImageLauncher Update Integration

Best Practices for Version Management

Handling Multiple Versions

Security Considerations

Verify AppImage Signatures

Download from Trusted Sources

Verify File Integrity

Run with Appropriate Permissions

Sandboxing Considerations

AppImageLauncher Security Features

When to Be Cautious

Reporting Security Issues

Flatpak vs AppImage Comparison

Distribution Model

Dependencies

Updates

Size Comparison

Desktop Integration

Security & Sandboxing

Use Cases: When to Choose Each

Choose Flatpak when:

Choose AppImage when:

Arch-Specific Considerations

Background Execution with `&`

Detaching Processes: `disown`

Using `nohup` for Long-Running Tasks

Using `setsid` for Complete Detachment