deezer-linux: packaging the Windows Deezer app for Linux, with patches

It is the Windows app, unpacked and patched

deezer-linux is described as an universal Linux port of Deezer, and the README is direct about what it is: an unofficial Linux port of the official Windows-only Deezer app, with a legal notice linked.

The important consequence of that approach is stated in the same paragraph. Because it is based on the native Windows app, it allows downloading your songs to listen to them offline. That is a feature the web player does not have, and it is the reason the port exists, because the Windows application is a real desktop client with a local media store rather than a page that streams to a browser.

The build is a patch pipeline, and the Makefile describes it precisely. The base URL and the SHA256 of the Windows installer are read out of the Flatpak manifest with jq, and the version number is extracted from the URL with a grep for a three-part version pattern. The source directory and the app directory are configurable, as is the package manager used for the build dependencies.

Then the steps run in order. The Windows installer is downloaded with wget into the source directory as deezer-setup-VERSION.exe, and the checksum is verified with sha256sum before anything is extracted, with the build exiting on a mismatch. The installer is unpacked with 7z, pulling out a plugin directory called app-32.7z, which is unpacked again. The asar archive is extracted with the asar tool through an npm script, so the app's JavaScript and HTML become a plain source tree.

That last step is the heart of it. Once the Electron app's resources are on disk as ordinary files, they can be formatted with prettier, patched with a set of patch files, and repackaged. The patches directory in the repository is the list of what the port changes, and the README links a specific one, the start-in-tray patch, from the launch options table.

Seven package formats, and the sandboxed ones need permission grants

The packaging table is the most useful part of the README for anyone deciding how to install it, because it maps each format to a situation.

The Flatpak is on Flathub, and the README calls it the easiest route along with the Snap Store, with one click, automatic updates, and working on any distro. The Snap goes through the Snap Store under the name deezer-desktop. The AppImage is a single portable file with no installation needed, downloaded from the releases page. The Nix version is in NixOS Nixpkgs, and the README gives both the configuration route and the one-shot command with nix-shell. There are rpm packages for Fedora, Red Hat, CentOS and openSUSE, deb packages for Debian, Ubuntu, Pop!_OS and elementary OS, and a tar.xz for any other distro.

The sandboxed formats carry a caveat that the README spells out. Flatpak and Snap packages are sandboxed, which means they have limited access to your system. It calls this a security feature, but notes it can cause issues with certain features, and says you may have to grant additional permissions using Flatseal for the Flatpak or snap connect for the Snap.

That is the honest trade-off of the two one-click options. The Flatpak gives you isolation and updates at the cost of the app's file access, and the permission you grant is exactly what determines whether the downloaded music can be found and played.

For the AppImage, the README recommends managing it with a helper so it gets a proper icon and menu entry, naming Gear Lever as a modern GUI and AppImageLauncher as an option that integrates on first launch, and there is a detailed manual route in the README for people who would rather register it themselves.

Four packaging targets means four manifests to keep in step

The repository keeps a separate manifest for each packaging system, and the differences between them are where most of the real work of the port lives.

The Flatpak has its own manifest, dev.aunetx.deezer.json, and the Makefile treats that file as the source of truth: the installer URL, the SHA256 and the upstream version are all read out of it with jq rather than being written twice. The Snap has a snapcraft.yaml, Nix has a default.nix and a shell.nix, and the desktop integration has a dev.aunetx.deezer.desktop entry file with a matching SVG icon, which matters for the AppImage and tar.xz installs that have no package manager to register them.

The themes/ and extra/ directories suggest the port adds more than patches to the app's behaviour. A themes directory is a natural home for the light and dark styling the README mentions as a launch option, and extra/ is where files that have to be dropped into the packaged app rather than patched into its source would live.

The Makefile also names the two maintainers at the top, Aurélien Hamy and Josselin Dulongcourty, which is a small signal about the shape of the project. This is a port maintained by a small number of people who track a proprietary application that ships new builds every couple of weeks, and the architecture of the build reflects that: everything that can be derived from a single manifest is derived, and everything that cannot is a patch that has to keep applying.

The repository also carries a CONTRIBUTING.md, a .prettierrc.json at the root that is copied into the extracted app during the build, and a .claude/ directory, which suggests some of the tooling work around the build is being done with AI assistance.

The launch command differs per package, and the options are patches

Launching the app is trivial from a menu, and the table of commands from a terminal is the useful detail.

For the Flatpak it is flatpak run dev.aunetx.deezer, and for the Snap, the Nix package, the deb and the rpm it is the deezer-desktop command in all cases. For the tar.xz and the AppImage it is ./deezer-desktop, run from the extracted folder or from the AppImage file itself.

The launch options are then a list of patches, and the README describes them as options to start in tray, sync theme and disable animations among others. That phrasing is revealing about how the port works. There is no configuration file to edit, because there is no source you maintain. Each behaviour is a patch file applied to the extracted app sources, so enabling an option is a matter of including its patch in the build.

The patch mechanism is what makes the port maintainable at all. The upstream Windows app is a compiled bundle, and the moment the vendor ships a new version the extracted sources change underneath the patches. A patch that no longer applies is a build failure rather than a silent breakage, because the Makefile applies each patch with patch and the build stops on the first one that fails.

The release version numbers give a sense of the pace. The listed releases are v7.1.330 from 2026-09-07, v7.1.320 from 2026-08-29 and v7.1.310 from 2026-08-24, so the project is tracking upstream releases roughly every week and a half, and the last push to the repository was on 2026-09-16.

The repository is packaging rather than application code

The top-level layout says what kind of project this is, and it is not a codebase that reimplements a music player.

There is a patches/ directory, which is the heart of it. There is dev.aunetx.deezer.json, the Flatpak manifest, and dev.aunetx.deezer.desktop plus an SVG icon for the desktop entry. There is a snapcraft.yaml for the Snap, a default.nix and a shell.nix for the Nix packaging, and a package-append.json that the Makefile merges into the extracted app's own package.json to add the Electron and electron-builder dependencies and the build directives. There is an extra/ directory, an icons/ directory and a themes/ directory, and a Makefile with the maintainers named at the top.

The small package.json at the root confirms the scope. It has two dependencies, the asar tool and prettier, and two scripts, asar and prettier. That is the entire build toolchain, and both tools exist for the same reason: the extracted Electron app sources have to be unpacked and then formatted consistently so that the patch files apply cleanly.

The formatting step is not cosmetic. The Makefile copies a prettier configuration into the app directory and runs prettier over the build JavaScript and HTML before patching, with the ignore path set to nothing so nothing is skipped. Patches are context diffs, and an application formatted to one standard is a patch that applies to a formatted application, so the reformat is what keeps the patch series from rotting on every upstream release.

The repository's licence is not stated in the metadata, while the underlying Deezer application it repackages is proprietary, which is what the legal notice in the README refers to.

Editorial conclusion

deezer-linux is worth using if you are on Linux and want the Deezer desktop application with its offline downloads rather than the browser player, because the port carries the real Windows app rather than a web wrapper and that is what makes downloaded tracks work at all. It is the wrong tool if you want a sanctioned Linux build, since the project states plainly that it is unofficial and carries a legal notice, and it is the wrong tool if you cannot accept a repackaged proprietary binary that has to be re-extracted and re-patched whenever the vendor ships an update. Before you install, verify three things yourself: that the package format you pick gives the app the permissions it needs, since the sandboxed Flatpak and Snap variants are documented as needing extra grants, and that the build script's checksum verification step is what you expect, because the Makefile downloads the Windows installer and checks its SHA256 before extracting anything.

Frequently asked questions

Official sources

1. aunetx/deezer-linux on GitHub
2. Issues
3. Project website
4. README
5. Releases