Build a package
The recipes are hand-written and live under packaging/, one directory per
format, each with its own README.md. What comes out is described in
Packages.
You need a checkout and the toolchain from Install from source steps 1 and 2.
RPM
mise run rpmThe result lands in dist/. Verified end to end against a clean fedora:44
container: build, install, five packages pulled in, wusel --version answers.
Debian package
./packaging/deb/build-deb.shAlso into dist/. This runs in its own debian:trixie container rather than on
the host, because the version of Rust a distribution ships is frequently below
what Wusel needs.
Arch
cd packaging/aur
makepkg -simakepkg runs on your own machine with network access, which is the AUR model —
unlike the two above.
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 extension and its emblem icons,
the app icon, and the search-provider and cloud-provider registrations.
Two details are worth knowing before you change anything:
-
The extension’s files are installed through the Makefile’s own
install DESTDIR=…target rather than being listed a second time in each recipe. One place to update when a file is added. -
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.