Papirus Icon Theme: Installing the Linux SVG Icon Set and What It Cannot Fix

The desktop problem Papirus actually addresses

Linux desktops resolve icons by name through the freedesktop icon theme specification. An application asks for an icon called something like `folder` or `text-x-generic`, and the theme supplies an SVG at the requested size. That indirection is why swapping a theme changes hundreds of applications at once, and it is also why the theme cannot touch anything that hardcodes an absolute path to its own icon files. Papirus is aimed at people who already run a GTK or KDE desktop and want a wider, more consistent set than the stock theme provides. The README describes it as an SVG icon theme based on the Paper Icon Set, with new icons and extras. The extras are the interesting part: Hardcode-Tray support, KDE colorscheme support and Folder Color support. Those are not icon drawings, they are mechanisms for reaching icons the theme system normally cannot reach. The repository ships three theme directories at the top level, `Papirus/`, `Papirus-Dark/` and `Papirus-Light/`, each with its own `index.theme`, which is the file the icon loader reads.

How a theme directory becomes a working icon set

Each variant is a directory tree of SVG files organised by size and category. The README's badge links point at paths such as `Papirus/48x48/apps`, `Papirus/22x22/actions`, `Papirus/22x22/panel`, `Papirus/48x48/places` and `Papirus/48x48/mimetypes`, so the layout follows the standard size-then-context convention. The Makefile confirms the shape of the thing: it globs `*/index.theme` to build its `ICON_THEMES` list, which means the three top-level directories are the unit of installation. Installing is a recursive copy into `$(PREFIX)/share/icons`, followed by `gtk-update-icon-cache -q` on each theme. That cache step is what makes lookups fast, and the Makefile deliberately skips it when `DESTDIR` is set, on the grounds that packaging should not build caches. The Makefile also carries a test suite: `test_short` runs checks for rendering glitches, optimization, SVG elements, symlinks, filenames, decimal sizes and length units, while `test_long` adds an XML structure check. Those tests exist because an icon theme is a large pile of hand-edited SVG, and a malformed path or a stray decimal in a coordinate is easy to introduce and hard to spot. The rendering-glitch test greps SVG path data for patterns that indicate a malformed number, which tells you the failure mode the maintainers worry about most.

Installing Papirus on Ubuntu, Arch, Fedora and everything else

On Ubuntu and derivatives the README gives a PPA. The package installs all three variants at once, as the comment in the command notes.

sudo add-apt-repository ppa:papirus/papirus
sudo apt-get update
sudo apt-get install papirus-icon-theme

Other distributions have their own packages, and the README lists the exact command for each: `sudo pacman -S papirus-icon-theme` on Arch, `sudo dnf install papirus-icon-theme` on Fedora 27+, `sudo apt install papirus-icon-theme` on Debian 9+ and Ubuntu 18.04+, `sudo emerge -a papirus-icon-theme` on Gentoo, `sudo apk add papirus-icon-theme` on Alpine, `sudo xbps-install -S papirus-icon-theme` on Void, `nix-env -iA nixos.papirus-icon-theme` on NixOS, and `doas pkg_add papirus-icon-theme` on OpenBSD. The README states plainly that these are third-party packages and that questions should go to the package maintainer, not the project. There is also a Snap. If you want the master branch rather than whatever your distribution shipped, the installer script is distribution-independent. The README documents three environment variables that control it: `DESTDIR`, `EXTRA_THEMES` and `TAG`. For a per-user install that GTK will pick up, the README gives:

wget -qO- https://git.io/papirus-icon-theme-install | env DESTDIR="$HOME/.icons" sh

For KDE the destination differs, and the README gives `DESTDIR="$HOME/.local/share/icons"`; on BSD systems it gives `DESTDIR="/usr/local/share/icons"`. The root install is the recommended one and uses the script with no environment variables at all, which leaves `DESTDIR` at its default of `/usr/share/icons`. The README marks one instruction as important: use the exact same command to update the icon themes. If you installed with `DESTDIR="$HOME/.icons"`, an update run without that variable writes to `/usr/share/icons` instead, and you end up with two copies and a theme that did not change. Removal is a separate interactive script, fetched from `https://git.io/papirus-icon-theme-uninstall`.

Hardcode-Tray, KDE colorscheme and Folder Color: the parts that go beyond drawing icons

Hardcoded icons are the reason this theme needs extras at all. The README's section on them opens with the observation that some software uses an absolute path instead of an icon name, which means the theme system never sees the request. Papirus splits this into hardcoded application icons, hardcoded tray icons and Steam runtime icons. The mechanism is Hardcode-Tray, an external tool the theme supports rather than contains; it patches the application's own files so they point at theme icons. That is a materially different operation from installing a theme. It edits files outside the icon directory, it has to be re-run after application updates, and it is the kind of change that a package manager will not track. The README does not promise it works for every application. KDE colorscheme support addresses a different gap: KDE applications that expect icons tinted to match the active colour scheme. Folder Color support lets folder icons take a chosen colour, and the related searches suggest `Papirus-folders` is the tool people associate with that, though the README excerpt does not spell out its interface. Treat all three as post-install steps with their own failure modes, not as features that come free with the SVG files.

Where Papirus stops being the right tool

The hardcoded-icon problem is the clearest boundary. If your applications bundle their own icon assets, or are Electron apps shipping a resources directory, or are Java applications loading from a jar, a theme swap does nothing for them. Hardcode-Tray covers some of that ground, but it is a patching tool, and the README does not claim universal coverage. The second boundary is scale. Papirus is a large repository of hand-maintained SVG files, and the Makefile's test targets exist precisely because that scale makes mistakes likely. If you need one specific icon changed for an internal application, the project's answer is the icon request process described in the README, not a local override. The third boundary is packaging lag. The README warns that some third-party packages may be outdated and directs readers to Repology to compare versions. A distribution that ships an old package gives you an old theme, and the installer script is the escape hatch. The fourth is that this is a desktop theme. It has no bearing on server installs, headless systems or anything that does not run an icon-loading desktop environment.

Papirus against the Paper Icon Set it forked from

The README states that Papirus is based on the Paper Icon Set. That is the most direct alternative, and the difference is scope rather than philosophy. Paper is the upstream design language; Papirus keeps that look and adds a much larger icon count plus the three extras described above. If you like Paper's drawing style but find its coverage thin for the applications you run, Papirus is the same lineage with more entries. If you want the upstream project's own curation and update cadence, use Paper. The practical difference for a packager is that Papirus ships three variants with separate `index.theme` files and its own installer and uninstaller scripts, while a smaller theme is often just a directory you copy. There is also an Android version, linked from the README as `papirus_icons`. That is a different codebase with a different delivery model, so a desktop package manager will not help you there.

Licence, maintenance and what upgrading costs you

Papirus is GPL-3.0. For a theme, the practical consequence is that redistributing it, modified or not, carries the obligations of that licence, and a distribution packaging it must comply. This is not legal advice, and anyone embedding the icons in a product should read the licence text in the repository's `LICENSE` file rather than rely on a summary. On maintenance: the repository is not archived, and the last push was on 2026-09-21. Releases are dated rather than numbered semantically, and the recent ones are 20260801, 20250501 and 20250201, which shows a cadence measured in months rather than weeks, with a gap between May 2025 and August 2026. Upgrade cost depends entirely on how you installed. A distribution package upgrades with the rest of the system and you get whatever the maintainer packaged. The installer script upgrades by re-running the identical command, and the README's warning about using the exact same command applies here: the environment variables are part of your install identity. Hardcode-Tray patches are the real recurring cost, because they live outside the theme directory and application updates can undo them. The repository also carries a `CHANGELOG.md` and an `AUTHORS` file, so the history of icon additions is traceable if you need to know when something changed.

Editorial conclusion

Adopt Papirus if you run a GTK or KDE desktop and want a broad, consistently drawn SVG set with per-distro packages and a script-based installer that does not care which distribution you are on. Do not adopt it if you need in-app icons from Electron, Java or bundled asset directories to change, or if you expect a single icon to be replaced without a pull request. Verify first that your package is current rather than stale: the README points at Repology for version comparison, and the third-party package list is explicitly maintained by other people. Then run the installer with the same environment variables you will use for updates, because the README states you must use the exact same command to update.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. PapirusDevelopmentTeam/papirus-icon-theme on GitHub
3. Project website
4. README
5. Releases