The updater is a part of the firmware, which installs and maintains packages. It has a few advantages over the usual package managers, mainly a new system of package management and new settings possibilities. Let us first have a look at the general differences between package managers.

Standard package managers, which are used for personal computers and servers, are programs, which know how to install packages. They act when commanded by the user. As a result, they function interactively - if there is a problem, they offer the user a solution and let him make the decision. What is more, they function at the level of individual packages. If the functionality of one package gets split between more packages, they don't try to automatically look for a solution.

opkg also falls into this category of packages and it doesn't carry out an update of the whole system - in order to keep implementation as economical as possible. It is maybe able to attempt a whole system update, but this brings the system to an unusable state in most cases.

The new updater combines some functions of standard managers (e.g. the ability to manage any package) and adds functions, which are specific to the router - mainly the ability to work completely autonomously. While running, the updater only informs the user and never actively asks.

In order to be able to carry out all these functions, the requirements and preferences must first be described in the configuration of the updater. The basic configuration usually only contains a list of repositories and a list of required packages, but it's also possible to describe preferences for solving problems or give a list of possible package candidates.

These are the basic slightly simplified steps, which the updater takes:

• It reads the configuration, part of it is local, part remote.
• It downloads the repository indexes (a list of available packages and their properties).
• Based on this information it calculates, which packages should be installed.
• It compares this set to the one that is currently installed.
• It makes necessary changes - it installs what is missing or is not upgraded and it removes what is excessive.

This has a couple of important consequences. First of all, the software that has been installed without the “awareness” of the updater will be removed during the next update. Second of all, every piece of installed software has to have a source (repository).

This method offers the most control over what happens. It's possible to edit the configuration files in /etc/updater/conf.d (any file in such path is loaded as configuration). They are in the programming language Lua and specific commands for the updater are described here (some parts are still not fully supported). The below mentioned commands are enough to set the basics.

After changes in the configuration, run the command updater.sh for the changes to apply straight away (and possible errors to be reported).

This command is followed by one or more package names - a request to install those packages:

Install("vim-full")
Install("strace")

It's also possible to add further parameters specifying the installation, these are described in the above mentioned documentation.

Adds a new repository. For example:

Repository("turris", "https://repo.turris.cz/omnia/packages/turrispackages", {
  ocsp = false,
  pubkey = "file:///etc/updater/keys/release.pub"
})

You don't need to add this specific repository, because it is already set in the default settings, but you can add your own.

The opkg command edits the file /etc/updater/conf.d/opkg-auto.lua, when a package is installed or deleted. It has the same syntax as the below mentioned user.lua, with the difference that it is edited automatically and so it is not recommended to manually interfere with it.

This method is simpler and it can also work through LuCI, on the other hand it is an imperfect abstraction, because the functions of opkg and the updater are principally dissimilar. This means that if you make bigger changes, unexpected things can happen.

Userlists or also lists of packages can be turned on in Foris. They usually activate a number packages with a similar functionality. Packages from these lists are also maintained better than the rest and are tested together.

Deleting a package using opkg causes the package to be deleted from the system plus it also deletes that package from /etc/updater/conf.d/opkg-auto.lua, if it was there. If the updater concludes that the package is needed for another reason, it brings it back.

These reasons can be any of the following:

• The package is part of the basis of TurrisOS. In this case the updater will require it, as Turris OS cannot exist in an infinite number of alterations and something has to be considered the basis.
• The package is pulled into the system from a userlist. For example the userlist NAS contains many packages, which you can but don't have to use. In that case the userlist can either be uninstalled and individual required packages installed or an absence of the packages can be enforced. How to do this is described below.
• The package is manually written into one of configuration files in /etc/updater/conf.d. The solution is to delete the package from that configuration file.
• Another package is dependent on it.

In some cases an absence of a package can be enforced via the following command in updater's configuration (i.e. file in /etc/updater/conf.d):

Uninstall("Unwanted_package", { priority = 60 })

Similarly to the command Install, which requires the package to be installed, the command Uninstall requires the package not to be installed. There is a conflict of demands, but because a higher priority is set (default is 50), one demand is overweighed. Be warned, this can lead to the removing of other packages, for example if they depend on that package.

This problem is commonly because of Uninstall command added most likely as a solution for previous problem. In such case removed package depends on package requested as to be absent and so it's removed. If you can accept to have package you requested to be absent on your system then just remove its Uninstall command from updater's configuration. If you insist on that package being absent then the only solution is to not to have all packages depending on it installed.