AUR vs Flatpak
Ditana supports both AUR packages (built locally with paru) and Flatpak applications (sandboxed from Flathub). Both have legitimate uses. The default Ditana recommendation is Flatpak first, with AUR as a deliberate fallback — but there are exceptions worth understanding.
When Flatpak is the better choice
Section titled “When Flatpak is the better choice”For most desktop applications, prefer Flatpak when a maintained Flathub package exists.
- Sandboxing. Flatpak applications run in a
bubblewrapsandbox with restricted filesystem and IPC access. For browsers, media players, and other internet-facing software, this is a real defence-in-depth layer. - No build time. AUR packages built from source can take minutes (or hours, for large applications like LibreOffice). Flatpak deployments download pre-built binaries from Flathub.
- No ABI risk. Binary AUR packages occasionally break when system libraries are updated and the upstream binary expects a different ABI. Flatpaks bundle their runtime and are insulated from that risk.
- Predictable updates. Flathub releases are versioned and easy to roll back. AUR is rolling and uncoordinated.
When AUR is the better choice
Section titled “When AUR is the better choice”There are three cases where Ditana prefers — or requires — AUR over Flatpak.
Chromium-based browsers under Ditana’s default hardening
Section titled “Chromium-based browsers under Ditana’s default hardening”Ditana disables unprivileged user namespaces (kernel.unprivileged_userns_clone=0) by default. This is a significant security improvement — it eliminates a kernel attack surface that has been the basis for several published local-privilege-escalation exploits.
The trade-off: Chromium-based Flatpaks fail to start under this setting, because their inner zypak layer creates additional user namespaces that bubblewrap-suid cannot satisfy. Firefox-based Flatpaks (LibreWolf, Mullvad Browser) lose only their browser-internal sandbox layer, but still work.
That is why Ditana ships Brave from AUR (brave-bin) rather than Flathub. The native Brave package uses its own setuid chrome-sandbox helper, which works flawlessly with userns=0 — no compromise needed on either security setting.
You can re-enable unprivileged user namespaces in the installer’s System Hardening dialog if you want to use Chromium-based Flatpaks. The dialog explains the trade-off where you make the decision.
Software not available on Flathub
Section titled “Software not available on Flathub”A non-trivial fraction of useful Linux software lives only on AUR — niche developer tools, vendor-specific drivers, hardware utilities, fonts. For these, AUR is the only option, and paru makes installing them straightforward.
When you want to participate in the AUR ecosystem
Section titled “When you want to participate in the AUR ecosystem”If you’re an Arch user who wants to follow AUR commit feeds, contribute votes, or maintain your own AUR packages, sticking with AUR for daily applications keeps you in that loop.
How Ditana decides at install time
Section titled “How Ditana decides at install time”The KDL configuration lets each setting declare both flatpak-packages and aur-packages. Where both are available, the choice is made deliberately, package by package, with a rationale captured in the relevant .kdl file. Browse ditana-config to see the reasoning in context.
Practical tip: review installed Flatpaks regularly
Section titled “Practical tip: review installed Flatpaks regularly”Flatpak runtimes accumulate. Run flatpak uninstall --unused occasionally to reclaim disk space — and flatpak update to keep applications current. Both are safe operations.