Build a package

The recipes are hand-written and live under packaging/, one directory per format, each with its own README.md. Every recipe produces two packages, wusel and wusel-nautilus; what they contain is described in Packages.

You need a checkout and the toolchain from Install from source steps 1 and 2.

RPM

mise run rpm

This runs packaging/rpm/build-rpm.sh inside a Fedora container. On a Fedora machine with the build dependencies installed through dnf, run that script directly instead. Both RPMs land in dist/. Verified end to end against a clean fedora:44 container: build, install — four packages pulled in for wusel, six with wusel-nautilus — wusel --version answers.

To build on a Fedora host without the container, run ./packaging/rpm/build-rpm.sh directly. It needs the build dependencies installed through dnf, including rust and cargo — the list is in packaging/rpm/README.md.

Debian package

mise run deb

Both .deb files land in dist/ as well. This runs packaging/deb/build-deb.sh inside a debian:trixie container, whose Rust comes from Debian’s own cargo and rustc packages — the same toolchain a real build service would install from Build-Depends. On a Debian-based machine with those build dependencies installed, run ./packaging/deb/build-deb.sh directly instead.

Both scripts build from HEAD through git archive, not from the working tree: commit first.

Arch

cd packaging/aur
makepkg -si

-i installs both packages it builds. makepkg runs on your own machine with network access, which is the AUR model — unlike the two above. It does not build your checkout: the PKGBUILD downloads the source tarball of the release tag named by its pkgver from GitHub. To package something else, change pkgver and sha256sums accordingly.

Why all three look the same inside

Each one compiles the same two things — cargo build --release --features fuse -p wusel and make -C integration/nautilus — and then stages the same file layout: the binary, the systemd user unit, the app icon, and the search-provider and cloud-provider registrations into wusel; the extension and its emblem icons into wusel-nautilus.

Two details are worth knowing before you change anything:

  • The DEB and Arch recipes install the extension’s files through the Makefile’s own install DESTDIR=… target. The RPM spec installs them by hand and lists them in %files nautilus, so a file added to the extension has to be added there too.

  • The cloud-provider registration is generated by running the freshly built binary, so it cannot drift away from the code that reads it.

Why RPM and DEB vendor their dependencies

Both are meant to build in a network-less chroot on a real build service — COPR, mock, sbuild, the Open Build Service. So each build script does two things that need the network exactly once, up front: git archive for the source and cargo vendor for the dependencies. After that, rpmbuild --rebuild and dpkg-buildpackage genuinely need nothing else.

The Arch build does not vendor, because makepkg runs on a machine that already has a network.

Only one dependency is mandatory

wusel declares one runtime dependency: fuse3, or the distribution’s equivalent. The binary links only libc, libm and libgcc_s, and its desktop integration speaks D-Bus without a library. wusel-nautilus and gnome-shell are Suggests / optdepends, so installing on a KDE or headless machine does not drag in the GNOME stack. Keep it that way if you add anything.

wusel-nautilus depends on wusel of the same version, and the RPM and DEB tooling adds the shared libraries the extension links against — the Nautilus extension library and GLib. GTK is compiled against but not linked, so it does not become a dependency. The RPM subpackage also carries Supplements: (wusel and nautilus), which makes dnf and zypper install it wherever Nautilus is.