Post History
Your question refers to a scenario in which software is installed by a DEB package, but also includes the ability to update itself independently of the package manager. This is very unlikely to wor...
#1: Initial revision
Your question refers to a scenario in which software is installed by a DEB package, but also includes the ability to update itself independently of the package manager. This is very unlikely to work well, and in my experience is exceedingly rare. Software is **either** installed as a DEB (or RPM etc) package, **or** it is installed with its own built-in update mechanism, **or** it is installed via FlatHub, Snap or other packaging systems¹. Trying to combine self-update with DEB packaging is likely to lead to some problems, depending on how the self-update works: 1. The DEB package installs the software to system-wide locations such as `/usr/bin` and `/usr/share` which are not writable by ordinary users. As a result, the built-in update mechanism fails because the user running the software does not have the necessary permission to replace the executable and other files. The self-update might succeed if the software is run with root privileges, but running arbitrary software as root is not generally recommended, and might cause other problems (such as writing data files that are not readable by non-root users). 2. In order to avoid the permissions issue, the self-update mechanism installs new versions to a different location than the original DEB package, such as under `$HOME/.local`. At this point, the DEB package is largely worthless because you're actually running a completely different copy of the software in a different location. Uninstalling the original DEB will not uninstall the newly-downloaded copy, because the package manager only removes files that were listed in the original package, and does not touch anything in user home directories or other locations. This could lead to a very confusing situation where you upgrade or replace the DEB and find it makes no difference to the version of the software you're running. 3. Self-update is a separate tool which needs to be run with root privileges (as in your example: `sudo foo-prog self update`). This might work, but as the answer by GeraldS explains, any files added or modified by the self-updater will **not** be tracked or uninstalled correctly by the package manager, which means you've lost all of the benefits of using a DEB package in the first place. At this point I can't actually think of an example of software that tries to combine DEB packaging with self-update in this way. Even software that normally updates itself on other platforms (e.g. Discord) requires you to download and install a new `.deb` if it was installed via the package manager on Linux. Software that is installed via a DEB and then downloads (and updates) **extensions** does exist — Visual Studio Code being a notable example. In this case it's doing a variation of item (2) above: the core executable can only be upgraded by installing a newer `.deb`, but the extensions go into `$HOME/.vscode/extensions` and can be updated within the software. ----- ¹ It's perfectly possible for more than one distribution or packaging option to exist for the same software, but typically you would pick just one of them for the actual installation.
