Native packages

Packaging trees for the three main Linux distributions live under packaging/. Each wraps the same binaries and assets; they differ only in packaging mechanics.

What a package installs

All three install:

• The binaries proton-syncd, proton-sync, and the desktop app proton-sync-gui into /usr/bin.
• A packaged systemd user unit at /usr/lib/systemd/user/proton-syncd.service (with ExecStart=/usr/bin/proton-syncd).
• The freedesktop launcher, AppStream metainfo, and hicolor app icons — so the app shows up in your menu and software centre. App id: app.protondrivesync.engine.
• The file-manager emblem icons and the Nautilus/Nemo Python extensions. On RPM and deb the extensions are separate optional packages (so a headless install doesn’t pull in the GObject/Python stack); on Arch they live in the single main package with the Python bindings as optdepends. See File-manager emblems.

The proton-drive CLI is not a dependency

None of the packages declare proton-drive as a dependency — it isn’t in any distro repo. secret-tool (for keyring session reuse) is a real, packaged dependency; proton-drive you install and log into separately, and it must be on PATH.

All three build the Rust workspace directly against crates.io (the Tauri/webkit stack isn’t individually packaged in distro crate ecosystems) and need a Rust edition-2024 toolchain (Rust ≥ 1.85). On RPM and deb the cargo build step itself fetches from the network, so the build chroot needs network access. On Arch, prepare() runs cargo fetch and build() is fully offline (--frozen), so only the source clone / fetch step touches the network — as designed for makepkg’s restricted chroot.

Fedora / COPR (RPM)

The spec is packaging/rpm/proton-drive-sync-engine.spec, with -nautilus and -nemo emblem subpackages. Because the build fetches crates from the network, enable internet access for the build chroot:

# local mock build (needs a source tarball or a pushed release tag)
mock -r fedora-42-x86_64 --enable-network \
  --spec packaging/rpm/proton-drive-sync-engine.spec \
  --sources packaging/rpm/ \
  --resultdir /tmp/mock-result

On COPR, tick “Enable internet access during builds” in the chroot settings, or use the “Build from SCM” method while the project is pre-tag. Runtime deps (GTK3/WebKitGTK/libsoup3) are auto-generated by RPM’s ELF/soname dependency generator; libappindicator-gtk3 is a soft Recommends because Tauri’s tray loads it via dlopen at runtime.

Debian / Ubuntu (deb)

The tree is packaging/debian/, producing three binary packages: proton-drive-sync-engine (main), proton-sync-nautilus, and proton-sync-nemo. dpkg-buildpackage expects ./debian, so symlink the tree into place from the repo root:

ln -s packaging/debian debian
dpkg-buildpackage -us -uc -b
rm debian   # remove the symlink afterward; don't commit it

Build-deps include debhelper-compat (= 13), a Rust ≥ 1.85 toolchain, pkg-config, and the Tauri dev libraries (libwebkit2gtk-4.1-dev, libsoup-3.0-dev, libgtk-3-dev, libglib2.0-dev). The emblem extensions are split into their own proton-sync-nautilus / proton-sync-nemo packages and wired as Enhances:/Suggests:, not hard dependencies.

Arch / AUR (PKGBUILD)

The recipe is packaging/arch/PKGBUILD (a single package, not split — the emblem Python bindings are optdepends):

cd packaging/arch
makepkg -si

makepkg needs an edition-2024 Rust toolchain, the Tauri build libraries, and network access to fetch the source. Before submitting to the AUR, regenerate .SRCINFO:

makepkg --printsrcinfo > .SRCINFO

After installing

Create your config, then enable the user service. The sample config’s installed path differs per package — Fedora ships it at /usr/share/doc/proton-drive-sync-engine/proton-sync.toml, Arch at /usr/share/doc/proton-drive-sync-engine/examples/proton-sync.toml, and the Debian package doesn’t ship it (use examples/proton-sync.toml from the repo):

install -Dm600 <sample-proton-sync.toml> ~/.config/proton-sync/proton-sync.toml
$EDITOR ~/.config/proton-sync/proton-sync.toml
systemctl --user enable --now proton-syncd

Make sure proton-drive is installed, on PATH, and logged in first. See Running as a service.

Pre-release

No v0.1.0 git tag exists upstream yet, so the RPM/deb source references and the AUR PKGBUILD source= need either a pushed tag or a locally-generated source tarball. Each packaging tree’s README.md documents the exact prerequisite.