Oh, I also ran:

$ rpm -qip *.rpm
Name        : syncthing                                                                                                                                                     
Version     : 2.0.14~dev.9.g4edc1d8d~rpm~packages                                                                                                                           
Release     : 1                                                                                                                                                             
Architecture: x86_64                                                                                                                                                        
Install Date: (not installed)
Group       : default                                                                                                                                                       
Size        : 31562463                                                                                                                                                      
License     : MPL-2.0
Signature   : (none)
Source RPM  : syncthing-2.0.14~dev.9.g4edc1d8d~rpm~packages-1.src.rpm
Build Date  : Wed 21 Jan 2026 04:56:41 PM EST
Build Host  : P14s
Relocations : /
Packager    : Syncthing Release Management <[email protected]>
Vendor      : Syncthing Foundation
URL         : https://syncthing.net/
Summary     : Open Source Continuous File Synchronization
Description :
Open Source Continuous File Synchronization
Name        : syncthing-discosrv
Version     : 2.0.14~dev.9.g4edc1d8d~rpm~packages
Release     : 1
Architecture: x86_64
Install Date: (not installed)
Group       : default
Size        : 23317001
License     : MPL-2.0
Signature   : (none)
Source RPM  : syncthing-discosrv-2.0.14~dev.9.g4edc1d8d~rpm~packages-1.src.rpm
Build Date  : Wed 21 Jan 2026 04:57:36 PM EST
Build Host  : P14s
Relocations : /
Packager    : Syncthing Release Management <[email protected]>
Vendor      : Syncthing Foundation
URL         : https://syncthing.net/
Summary     : Syncthing Discovery Server
Description :
Syncthing Discovery Server
Name        : syncthing-relaysrv
Version     : 2.0.14~dev.9.g4edc1d8d~rpm~packages
Release     : 1
Architecture: x86_64
Install Date: (not installed)
Group       : default
Size        : 12411748
License     : MPL-2.0
Signature   : (none)
Source RPM  : syncthing-relaysrv-2.0.14~dev.9.g4edc1d8d~rpm~packages-1.src.rpm
Build Date  : Wed 21 Jan 2026 04:57:51 PM EST
Build Host  : P14s
Relocations : /
Packager    : Syncthing Release Management <[email protected]>
Vendor      : Syncthing Foundation
URL         : https://syncthing.net/
Summary     : Syncthing Relay Server
Description :
Syncthing Relay Server

Just amended the commit to include Signed-off-by as requested by DCO.

Thanks for asking and for your time, @calmh.

As I said in the initial PR comment, I was only able to test on x86 Fedora 43, but it worked for me. I'm unclear what testing you guys currently do to test installation of the .deb packages that you currently build but I'd happily help consider those so that these rpm packages match the current process.

This is useful to me and others like me who like having the up-to-date versions of software, published by the upstream maintainers. I personally use reprox.dev to add Github Repos to my distro's package manager so that these packages automatically download and install, but anybody on Fedora, CentOS, RHEL, etc could download and install from your repo to get Syncthing 2.x. Fedora's next update is still tracking 1.30 in their official repos.

I guess the short answer to your question is: The answers to your "why would we do this with rpm?" questions would be the same as the answers to "why do we currently do this with deb?" questions.

Oh it's not so much a question of why as how, the why is clear. :)

I see your reprox.dev and while that seems neat, I don't think we'd opt to rely on that from day one. Rather, we'd need a yum/dnf repo published to an s3 bucket and a page like apt.syncthing.net to guide about the usage of said repo. "Just" dropping RPM packages on our releases page seems like a regression as users are likely to grab them and then never get an upgrade, as opposed to getting an auto upgrading binary if they just download our distro-agnostic tar.gz today.

I don't think we do any specific testing today of the Debian packages, but they are installed and run by many tens of thousands of users on each release, so they're fairly tested at this point. The RPM packages on the other hand are an unknown, and once we release and point to them it'll be quite important that they work reasonably well or the support burden may become significant. I, personally, don't run any rpm based distro and I'm not familiar with how things like firewalls, SELinux, etc typically work there and what the expectations are on that. Nonetheless, I expect that as soon as this is merged it will become my responsibility to maintain.

Well, we don't do any SELinux or firewall stuff if we ship a simple tar.gz either, so that's not really an argument against it IMHO.

My minimum requirement would be having a few contributors running RPM based distributions. I run Fedora on my laptop, but I lack a deep understanding of RPM packaging.

I hadn't factored in how these .deb packages are part of the larger PPA infrastructure that you also run. Great points.

Well, we don't do any SELinux or firewall stuff if we ship a simple tar.gz either, so that's not really an argument against it IMHO.

That depends on what the community expectations are on a packaged RPM. I honestly don't know. It may be perfectly expected to not do anything at all here, or it may be that everyone knows that you just dnf install foo && firewall enable foo and it's supposed to just work. I expect someone who lives in these distributions to let us know.

Perfect is the enemy of good 🤷 We can still add that to our rpm if someone asks for it.

I'm not saying it has to be perfect. I'm saying at least someone who is used to an rpm based distro should chime in with how that usually works.

dude chill..... use this COPR https://copr.fedorainfracloud.org/coprs/gotmax23/syncthing-ng/

@vw090 I do not want to use the upstream rawhide branch built by a rando whose latest builds are failing, but thanks.