Putting the binary in `/bin`

[shetozz (SHETOZ)]

I downloaded the latest release and just moved the binary into /bin to replace my previously installed binary that I got through dnf -I’m using Fedora-.

Is there anything else I should take into consideration for it to work well, or this will do the trick?

[AudriusButkevicius]

It might not be able to self update this way.

[gadget]

@shetozz

Is there anything else I should take into consideration for it to work well, or this will do the trick?

/bin

Ideally, stuff under /bin (technically /usr/bin because /bin is a symlink) should be left to the OS. Manually replacing a file installed by the package manager will cause conflicts when upgrading packages to newer releases – i.e. DNF still thinks that it was the one who installed Syncthing, so DNF will either downgrade your newer /usr/bin/syncthing or spit out an error the next time dnf upgrade is run.

It also means that Syncthing’s built-in auto-upgrade and the upgrade button in its web UI won’t work because /usr/bin/syncthing is normally owned by root, so you’ll need to manually replace /usr/bin/syncthing as needed. (Fedora compiles Syncthing with auto-upgrade disabled.)

If Syncthing must be available to multiple users, it’s better to put it under /opt (short for “optional”) in a /opt/bin, /opt/syncthing, or some other choice of subdirectory. /opt/syncthing is ideal because the directory and file ownership are easy to manage to allow Syncthing to auto-upgrade itself (if that’s of interest).

/usr/local/bin

Alternatively, /usr/local/bin is another option, but setting up auto-upgrade is more complicated because Syncthing can’t normally write anything else there so it won’t be able to create a temporary file during upgrades.

~/bin

If Syncthing is only going to be used by a single user, the best option is ~/bin. By default the subdirectory doesn’t exist, but it’s part of the default search path. Since it’s owned by the user running Syncthing, the upgrade button in the web UI and auto-upgrades work as expected.

• Some users don’t like to see a ~/bin subdirectory, so ~/.local/bin is another option if having it hidden is preferred.
• It’ll avoid confusion later if the system package is uninstalled, but since ~/.local/bin and ~/bin are searched before /usr/bin there’s generally no conflict at a shell prompt.
• However, it’s not necessarily true for a desktop environment. For example, launching Syncthing from the “Activities” menu in GNOME loads /usr/share/applications/syncthing-start.desktop, which in turn runs /usr/bin/syncthing.

systemd

If using systemd to auto-start Syncthing, anything other than /usr/bin/syncthing requires updating the systemd unit file for Syncthing (e.g. /usr/lib/systemd/user/syncthing.service).

And if you remove the system package for Syncthing, you’ll have to create your own systemd unit file (e.g. /usr/local/lib/systemd/user/syncthing.service).

SELinux

As a service, Syncthing runs unconfined under SELinux on Fedora, so no potential issues there.

[239]

@gadget

And if you remove the system package for Syncthing, you’ll have to create your own systemd unit file (e.g. /usr/local/lib/systemd/user/syncthing.service).

Or copy it to ~/.config/systemd/user/syncthing.service and replace

ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0

with

ExecStart=%h/.local/bin/syncthing serve --no-browser --no-restart --logflags=0

or any other path in your home, without root access.

[shetozz (SHETOZ)]

Thanks guys for the useful tips, I totally missed the point of dnf getting confused, The only reason I did it this way, I didn’t want to modify the .desktop file, but that turned out to be lazy and dumb