RPM dependency fuse2-libs is unavailable on Fedora 44

[ARUNMANIKANDAN-C]

Summary

Fixes #512

This PR fixes the RPM dependency issue reported on Fedora 44, where the Tuttle RPM package could not be installed because it explicitly required the distribution-specific fuse2-libs package.

Fedora 44 provides the required FUSE 2 ABI through the fuse-libs package, including:

libfuse.so.2()(64bit)

The previous RPM configuration declared:

"rpm": {
  "depends": [
    "zlib",
    "fuse2-libs"
  ]
}

This caused installation to fail on Fedora 44 with:

Problem: conflicting requests
  - nothing provides fuse2-libs needed by Tuttle-4.2.1-1.x86_64

Changes

• Removed the distribution-specific fuse2-libs RPM dependency.
• Updated the RPM dependency to use the required FUSE 2 capability instead of relying on a specific package name.
• Verified that the generated RPM correctly declares the required dependency.
• Built and tested the modified RPM on Fedora 44 x86_64.
• Verified that the RPM can be installed successfully on Fedora 44 without requiring a package named fuse2-libs.
• Confirmed that the application launches and runs correctly after installation.

Verification

The original dependency was confirmed using:

rpm -qpR ./Tuttle-4.2.1-Linux-x86_64.rpm | grep -i fuse

Fedora 44's provided capabilities were verified with:

rpm -q --provides fuse-libs | grep -i fuse

which includes:

libfuse.so.2()(64bit)

The modified RPM was then built and installed on Fedora 44 x86_64 to verify that the dependency is resolved correctly.

Result

Fedora 44 users can now install the Tuttle RPM without encountering the unavailable fuse2-libs dependency.

This also makes the RPM dependency more portable across RPM-based distributions where the FUSE 2 ABI may be provided by packages with different names.

Checklist

• I have read the Contributing guide.
• I have installed and tested the application for my platform (just dev).
• The test suite passes locally (just test).
• Pre-commit hooks are installed and pass (just precommit).
• I have added or updated tests where appropriate.
• I have updated the RPM dependency configuration.
• I have built the modified RPM.
• I have tested RPM installation on Fedora 44 x86_64.
• I have verified that the application launches successfully after installation.
• I have verified the resulting RPM dependency metadata.
• I understand and can explain all submitted changes; if AI assistance was significant, I have disclosed this in the summary above.

[clstaudt]

Thanks for the contribution @ARUNMANIKANDAN-C, and for the thorough investigation in #512!

A few changes needed before this can be merged:

1. Use an RPM capability instead of a package name

The PR replaces fuse2-libs with fuse-libs, but that's still a Fedora-specific package name — other RPM distros may use a different name and hit the same problem. As you noted in the issue, Fedora's fuse-libs provides libfuse.so.2()(64bit). electron-builder supports capability strings in RPM depends, so please use that instead. This makes the dependency truly portable.

2. Justify or remove the additional RPM dependencies

The issue was about one dependency, but this PR adds 9 new ones (nspr, gtk3, libnotify, nss, libXScrnSaver, libXtst, xdg-utils, at-spi2-core, libuuid). These aren't discussed in the issue or PR description, and some are also distro-specific names that could cause the same problem elsewhere. Please explain which are actually needed, or remove them.

3. Split the workflow into a separate PR

The packaging fix and the 1000+ line CI workflow are independent concerns. The package.json fix can land quickly on its own; the workflow can be reviewed separately.

4. Workflow security concerns

When the workflow PR comes in, please address:

• Remove --privileged from Docker runs — not needed for an RPM build, grants unnecessary host capabilities
• Pipe-to-shell installs (curl | bash) are a supply-chain risk, especially combined with --privileged
• --allowerasing on dnf install can silently remove packages and mask real dependency conflicts

[ARUNMANIKANDAN-C]

@clstaudt thanks for review

I’ll work on the CI/CD pipeline separately.

As part of the testing, I ran the RPM built by the workflow across three RPM-based distributions:

• Fedora 44
• Rocky Linux 9
• CentOS Stream 9

The workflow installs the generated RPM, verifies its dependencies and shared libraries, and launches the Tuttle application under Xvfb. The application completed the smoke test successfully on all three environments without Tuttle-specific crash dumps or abnormal exit codes.

I’ll separate this CI/CD work from the packaging fix and address the security concerns you mentioned (--privileged, pipe-to-shell installs, and --allowerasing) in a separate PR.