P.S. >> Considering these points, I do not know, what you mean by "unbundling >> libsyncthing". Since, the upstream source of libsyncthing is the >> Syncthing Tray there should be no other source package for libsyncthing, >> and since libsyncthing is not built (and IMHO shouldn't, because it is >> still experimental) there is no libsyncthing.so that could be unbundled >> from the binary package. >> > > The definition of "unbundling" depends on the context. Sometimes it > means a source package split, but in this case it means deleting > Marchus' fork from Syncthing-Tray's source. If it's unused, then this > shouldn't cause any problems at this time. If at some point it becomes > default then it is better for the build to fail loudly rather than link > against a custom libsyncthing. At that time the decision becomes: 1) > depend on Debian's Syncthing source and link it into the expected place, > or use a build-system config key to point Syncthing-Tray's build system > to the correct location. 2) Use a build-system config key to explicitly > disable this functionality. >
I can't remember what I found when I investigated this, but was it that libsyncthing.so was used to provide an embedded copy of the Syncthing server? If so, it seems to me that the correct course of action is to forever disable it, because Syncthing Tray should use the Debian-provided Syncthing (user-specific) systemd service. In addition to correctness, in combination with "loginctl enable-linger user" this allows the Syncthing daemon to continue to run if X crashes (or is killed), or when the user logs out without shutting down the system. IIRC if Syncthing Tray wants to manage Syncthing daemon startup (ie: other than the restart and shutdown functionality provided by the web GUI), then it should use systemctl --user or the dbus interface. This is a problem for post cpp-utilities and post qtutilities upload of course.
signature.asc
Description: PGP signature
