Self-updating on systems with a package manager (Linux)

[FichteFoll]

We talked about this a couple of times on IRC, but I'm finally making an issue for it.

So, there are no binaries for DepCtrl's dependencies, notably ffi-experiments, which is why someone (myself) created a package for the entire thing on the AUR. As all sane packages do, this one installs depctrl (and its deps) into a system folder, i.e. aegisub's application folder's automation folder in /usr/share/aegisub/automation.

It is very much untested terrain for when DepCtrl finds an update of itself and attempts a self-update, since that would most likely have all or some of the following issues:

1. DepCtrl downloads the self-update and puts it into the user's ~/.aegisub/automation folder, which will from now on always take priority over the system version and shadow any updates of it by the AUR package.

2. Currently, it's not specified anywhere that DepCtrl's dependencies (i.e. ffi-experiments) are available. I don't know why it works currently, but I suspect that depctrl doesn't actually verify whether its own dependencies are available on startup and only on update. However, when it checks for ffi-experiments on an update and attempts to download it, there are no releases for Linux-x64, so the update will fail?

In case the update fails entirely (2.), this would be awesome because it means the first case hopefully wouldn't come into play as the file is never written. That allows to add a workaround or a non-self-update mode through either some flag or by checking whether depctrl files exist in the application aegisub folder.

In case the update succeeds partially (1.), then the shadowing file needs to be removed in case DepCtrl is to be managed by an external package manager, so that it doesn't shadow anymore. Note that a package manager itself cannot reasonably do that as this would affect the user's home folder.
However, when the updated DepCtrl then removes itself, the old version will be loaded on the next start of Aegisub (or when automation is reloaded) and the same procedure would occur again.

Ultimately, there are two solutions:

1. Have DepCtrl support Linux.
2. Add a way to prevent DepCtrl from updating itself.

As the former is somewhat unfeasible with the Linux binaries and all the different distros to think of, having a distro-specific package manager take care of building the binaries and installing that as a package seems much more feasible. Thus, there needs to be a way of signaling DepCtrl that it should not self-update (or any of its dependencies).

For doing that, I can see the following three options:

1. Configure/Hardcode in the source. During the build process, the source code could be adjusted to switch a flag that would disable self-updates. (could do that 2. DepCtrl-related files (or just a single one) exist in the system/installation folder of Aegisub.
2. Some other configuration file in either the install folder or some global configuration folder (e.g. /etc) disables self-updates through its presence or a config option.

I believe the latter to be the most practical and flexible by a large margin.