Spksrc: Syncthing package v1.3.4

[Kaelber]

The current version of Syncthing is v1.4.0 and tomorrow v1.4.1 will official release. Until v1.4.0 a new database layout is implemented and the database needs a migration from versions <1.4.0, so also from v1.2.2 or v1.3.4.

The new database layout could be a confusion, if a user use the inside updater function and update the system files from the old v1.2.2 to the newest one, today v1.4.1-rc.3. I also doe that.

Now you update your packkage from v1.2.2 to v1.3.4 and messed with the above facts, because a re-migration is not possible and the package crashes. Next is, why you did not go straight to v1.4.0 is also not clear to me, because of course many of the updater are surely now at least on v1.4.0 or even on v1.4.1-rc.3. The database schema no longer fits. Next is now, the whole package no longer runs after the update.

In any case, you not paying attention. I must therefore deleted the SC package.

[acolomb]

There is already an ongoing discussion in #3884.

[ymartin59]

@Safihre We already had such a discussion - but here is a perfect scenario to motivate my willing to disable "in application live update" (moreover it is probably not functional for some architectures)...

[acolomb]

@ymartin59 I see you found the right issue about an unfortunate Syncthing version.

Disabling in-app upgrades would be fine and is what many people would expect from a "managed" package anyway. It requires looking through DSM notifications for upgrades more often, but I think people can live with that.

If we go down that route, there should be a process though to ensure more timely SPK updates. I'd volunteer to push Syncthing releases more often, but it doesn't help if the limiting factor is your time to review PRs and sift through e-mails. Which I totally understand, no offense intended.

Please review my thoughts about the broader matter in this comment, which apparently went under your radar as well.

[acolomb]

@ymartin59 While trying to rebase PR #3931 onto current master, I hit some problems regarding PKG_DIST_FILE in cross/syncthing/Makefile:

make[3]: Entering directory '/spksrc/cross/syncthing'
===>  Downloading files for syncthing
===>    File syncthing-1.4.0.tar.gz already downloaded
===>  Verifying files for syncthing
===>    Downloaded file syncthing-1.4.0.tar.gz not in digests file
../../mk/spksrc.checksum.mk:42: recipe for target 'checksum_target' failed

The PKG_DIST_NAME points to syncthing-source-v1.4.0.tar.gz, while in PKG_DIST_FILE the -source part is missing. I don't know if that's intentional, but just removing that second definition apparently makes it compile fine.

[acolomb]

@Kaelber builds of Syncthing v1.4.0 now available on my fork.

These are completely untested, use at your own risk!

[Kaelber]

Because I run currently the Kastelo version I get after starting the installation a message about a used port. I think is 8384 which is used now. Normaly the SC package use port 7070, why also not during installation? In the current way no installation is possible.

[publicarray]

Should be fixed with https://github.com/SynoCommunity/spksrc/commit/00823cb1c648ddaccf5f9d04d8658e555234cea2 download: https://synocommunity.com/package/syncthing (note the site is under heavy load and might timeout)

Can this be closed?

[acolomb]

Syncthing from SynoCommunity has been using port 8384 for the GUI for a long time, because that is Syncthing's standard upstream. See https://github.com/SynoCommunity/spksrc/wiki/SynoCommunity-Used-Ports.

Just stop (shutdown) the other service to free the port for testing this package.

Can be closed when positively tested I guess. Sorry I don't have the time to test for myself right now.

[Otiel]

Disabling in-app upgrades would be fine and is what many people would expect from a "managed" package anyway. It requires looking through DSM notifications for upgrades more often, but I think people can live with that.

I disagree. Syncthing auto-upgrade ensures that linked devices use the same Syncthing version, which is safer in order to minimize errors while syncing files. Other Syncthing wrappers use Syncthing auto-upgrade by default (SyncTrayzor for instance), so it doesn't seem to me like a bad pattern.

The auto-upgrade works fine as it is and doesn't require the SynoCommunity-Syncthing package to be updated. Disabling the auto-upgrade would:

• Introduce a new point-of-failure in the chain (and we've seen these past days that it can fail).
• Force someone to actively maintain the package for something that's already done automatically.
• Possibly delay Syncthing upgrades as it requires, as you've rightly wrote:
  
  
  
  • The spk to be updated.
  
  
  • The corresponding PR to be merged.
  
  

IMO, the only thing that we should improve is that a PR shouldn't be merged on spksrc/spk/syncthing if spksrc/cross/syncthing/digests doesn't correspond to the latest stable Syncthing release.

[Kaelber]

Disabling in-app upgrades would be fine and is what many people would expect from a "managed" package anyway. It requires looking through DSM notifications for upgrades more often, but I think people can live with that.

As a user and admin of 3 Synologys that is exactly my attitude and also normality. There are plenty of other examples of package updates that need to be initiated. It would only be one more.

[Kaelber]

I disagree. Syncthing auto-upgrade ensures that linked devices use the same Syncthing version, which is safer in order to minimize errors while syncing files. Other Syncthing wrappers use Syncthing auto-upgrade by default (SyncTrayzor for instance), so it doesn't seem to me like a bad pattern.

I do not agree with this.

Important updates can occur for various reasons. Change of program files, structure etc. as now in the database. Who of you is watching this? Of course, that could also be clustered into major key steps, but that's a risk. The conversion of the database is a vivid example of an important main step.

[Kaelber]

Syncthing from SynoCommunity has been using port 8384 for the GUI for a long time, because that is Syncthing's standard upstream. See https://github.com/SynoCommunity/spksrc/wiki/SynoCommunity-Used-Ports.

Just stop (shutdown) the other service to free the port for testing this package.

Can be closed when positively tested I guess. Sorry I don't have the time to test for myself right now.

Anyway no installation is possible, sorry. I think is the best to change to port 7070 for Synology packages, because this port is also used after installation.

[acolomb]

Port 7070 is only used if you have it configured in Syncthing, which might have happened with a much older SynoCommunity SPK. The current package even includes a predefined firewall rule for port 8384 so that is what Syncthing should use and does if not configured manually.

Using the upstream default port is recommended behavior in SynoCommunity and I strongly advise not to deviate from that.

On a historical note, I think Syncthing assigned random GUI ports by default in its early days, so that is why the standard 8384 was adopted later here.

Regarding your installation troubles, just don't start the service during installation, so you can change the port to 7070 in config.xml manually if required.

[ymartin59]

@acolomb There was already a PR for Syncthink 1.4.0 #3931 so I have reviewed, merged and published.

[acolomb]

@ymartin59 Thank you for your efforts. A little more coordination would have been nice,since at first it seemed that no maintainer is getting involved. But hey, the result counts in this case ;-)

[Kaelber]

I have never made any adjustments to the ports or like that. Port 8384 has always been in the GUI and port 7070 was used on the Synologys. The last new installation was about 1 year ago because a disk station was replaced and also with that installation port 7070 was used in the normal process.

Now I have implemented the Kastelo installation and even if I stop it, no installation of the SynoComm package is possible. As you know, we already discussed the two packages from SynoComm and Kastelo in the Syncthing Forum and I do not name the curiosities that existed in the past.

Here, too, I advise cementing the independence of the past. Kastelo uses port 8384, SynoComm. Port 7070. BTW, it has always been that way since I use SynoComm. package with Syncthing v0.13, therfore its for me a kind of standard.

[Safihre]

@ymartin59 It's a bit strange we update the package if it has an inside updater, why would we update the package at all?
Packages with build in updates need checks that they don't overwrite a more recent self-update. Like we do for sonarr and radarr, the update includes a version check. Seems we should also do this here and then just not touch the package again?

[Kaelber]

This question shows that the topic was not understood.

If no SPK updates are to be made with every syncthing update, then milestone updates are absolutely necessary to take important main steps into account.

Further, if you handle that in your old way, it means installation of vX.X.X and then updates internally to Y.Y.Y this would be deemed unacceptable by any packaging systems also. Version upgrades are supposed to happen through the packages, not willy-nilly.

And I repeat: Important main steps can occur for various reasons. Change of program files, structure etc. as now in the database.

[acolomb]

@Safihre Nice idea, but it should be limited to the binary itself. Any updates to the packaging should of course come through.

By the way, the current release v1.4.1 (out today) includes an improvement to the internal update logic so it should better cope with the situation in this issue. Checking for upgrades happens before it chokes on the incompatible database.

[acolomb]

@Kaelber The way I see it, Syncthing uses port 8384 for its GUI. Should not matter who packaged it, as any Syncthing user on any host should find the same defaults. Manually changing from the defaults is a totally different scope, anyone is free to do so but might lose the firewall integration and should expect things to work differently.

PR #3395 was merged in July 2018 so if you have a configuration with port 7070 it was probably created before that. Whatever port you want to use, if it is not used by another application and Syncthing still does not start, please provide more details so we can diagnose that issue.

[acolomb]

@Safihre I don't know about Sonarr and Radarr, but at least Syncthing is a compiled application, so the toolchain used for its official self-update binaries likely differs from what Synology uses, even if the architecture basically matches. Running those foreign binaries on DSM might lead to really hard to find bugs.

So that's one argument for leaving updates to the packaging system and not the application (which Syncthing itself supports and recommends). I'd like to repeat my offer to help with keeping up to date with upstream, if we follow that direction. Losing timely updates because of lacking maintainer capacity would be sad though.

[ymartin59]

Another option is to create a pre_upgrade validation script in syncthing package for DSM to prevent possibility for user to accept a downgrade of its syncthing version when already running a more recent version of code and database schema.
For updates, please submit PR and does some testing, it may be far enough.

If you want to publish package on your own, please request an account to @Diaoul on spkrepo instance and generate an API key. If I remember well @Safihre already did.

[Kaelber]

This would mean that a package update would only be possible after installation if the version contained in the package corresponds to the current release of Syncthing. If someone who also allows RC wants to update, they have to be really lucky. Or you are incredibly fast and should never take an older version, like now with v1.3.4.

V1.4.2-rc.1 has already been released today, some hours after the today release of v1.4.1. In addition, v1.5.0 is already being considered with a different GO.

Then what about the perpetual update message in Synology DSM that could never be fixed?

[ymartin59]

Probably it is not wise to deploy an release candidate (as "rc" means) in "production"... by the way, some time is required for testing and evaluate stability of built binaries.
Syncthing is not the only package delivered here, I hope you are aware of current "backlog".

[Kaelber]

The circumstances with the RCs are exactly what you can allow with the current SPK. Even if the user has a choice.

Additionally I think, that the future release v1.5.0 is also a major step as v1.4.0. What is your thinking to handle that? Is this managed in a standard SPK you want to use for all packages?

That is the message from the today Syncthing Website:

... latest Syncthing release is v1.4.2. The next release, v1.5.0, is expected 2020-05-05 ...

[Safihre]

@Kaelber I am having a bit hard time to understand what it is that you are proposing we should do?
The discussion about the ports Syncthing uses also makes these posts hard to follow.

[Kaelber]

I just mean, if you decide not to create an SPK with every Syncthing Release Update, at least any main steps should be under control. A main step for me was the update from v1.3.4 to v1.4.0 and the next main step for me is from v1.4.2 to v1.5.0 on May 5th, 2020.

How is this managed so that adverse processes do not occur again, as discussed here at the beginning.