Verified Commit 138c9e84 authored by Karel Koci's avatar Karel Koci 🤘
Browse files

pkgupdate: remove interaction documentation

This is no longer valid. All this is now implemented differently or is
going to be shortly.
parent 04dd2d52
Pipeline #71822 failed with stages
in 4 minutes and 32 seconds
Interaction with the rest of the system
=======================================
The updater interacts with other components on the system. In addition
to the obvious (it updates them), it has some configuration and
reports its doings. A part of the interaction is done by the
`updater.sh` wrapper script.
Overriding its default behaviour
--------------------------------
It is possible to turn the updater off by setting the uci option
`updater.override.disable` to `1`.
It is also possible to take updates from a development branch. It can
be configured by the `updater.override.branch` option. It may be
needed to install the `cznic-repo-keys-test` package.
Package selection
-----------------
Packages to be installed are taken from two places. The first one are
lua configuration files in `/etc/updater/auto.lua` (auto-generated by
the `opkg` wrapper) and `etc/updater/user.lua`.
The second are lists of packages provided by the server. Each list may
be enabled by uci in `updater.pkglists.lists`.
Action reporting
----------------
The updater produces several status files in `/etc/update-state`. The
most important is `state`, which contains the action the updater is
doing right now. The values may be:
done::
Operation of updater terminated without errors.
error::
Something went wrong, the updater terminated with an error.
lost::
Something went wrong. This is different from the above in the way
that the `pkgupdate` backend of updater didn't even provide the
`error` status, it simply crashed.
startup::
Early stages of the updater, it is initializing itself.
get list::
The updater is downloading package lists and repository indices
from the server.
examine::
The updater is planning and thinking about what to do.
install::
It is installing a package.
remove::
It is removing a package.
The next file is `error`, which contains the reason something went
wrong, if it is known.
The last one is log2, which contains list of actions performed during
the latest run. Each line is single action, prefixed with a letter
specifying the type of action.
`D`:: Download of a package.
`I`:: Installation of a package.
`R`:: Removal of a package.
They are followed by a package name and a version (if applicable, `R`
doesn't contain the version).
It also produces a log of installations and removals on permanent
storage, in `/usr/share/updater/updater-log`. This one contains time
for each action and the packages being installed or removed. This one
is not suited for real-time observing of the updater actions (all the
actions of one run are written at once), but more for after the fact
examination of what went wrong.
After the updater finishes, it produces a notification (with either
the actions performed, or with an error message).
Approvals
---------
The updater may be made to ask for an approval of its actions. There are
three options regarding this:
`updater.approvals.need`::
If this is set to `1`, the updater needs to wait for an approval
from the user.
`updater.approvals.notify`::
Usually, the updater creates a notification whenever there's a
need from the user to approve something. Setting this to `0`
disables this creation of notifications.
`updater.approvals.auto_grant_seconds`::
If this is set, the approval is automatically granted after so
many seconds since asking for it.
Whenever there's a need for an approval, the file
`/usr/share/updater/need_approval` exists. Its first line is ID of the
approval. Further lines list the actions the updater wants to take.
There's also the `/usr/share/updater/approval` files, listing status
of approvals. Each line consists of an ID of an approval, its status
and a time when it was asked for. The status may be any of:
`asked`::
The updater asked for this approval, but it wasn't granted by the
user yet. It might be granted automatically, if the
`auto_grant_seconds` is set.
`granted`::
The user granted the updater an approval to go on with this change
set.
`denied`::
The user has explicitly forbidden to perform this change set. It
will not be granted automatically, even if the
`auto_grant_seconds` is set.
All the `granted` and `asked` lines are removed once the update is
performed ‒ the approvals get used up and if there's the same change
set again, it needs to be re-approved. The `denied` lines are not
removed automatically ‒ they are permanent in a sense.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment