GitLab

Fixed
* error on transaction recovery created by updater before version 69.0.1
  about `upgraded_packages` being nil

On update the old transaction created by updater version before 69.0.1
does not contain this field. We should not expect it. In worst case it
is going to be reported as not upgrade as it was previously.

Changed
* Package requests solver no longer tries to maximize number of selected
  requests but rahter follows strictly rules of requests priority
* `Install` requests with same priority as `Unistall` are resolved first
* `Install` and `Unistall` requests without condition as resolved before
  requests with condition given they have same priority specified.

Removed
* Error reported when request to install and unistall same package was
  specified

The original implementation tries to satisfy maximum number of requests
in given priority level. This has been seen as ideal solution because
this way most of the user's requests are satisfied.
This changes this behavior to rather be strictly defined. This means
that we do not care about number of requests satisfied. We care only
about priority of request and satisfy them in order.

This also removes error raised when there was Install and Uninstall
request for same package with same priority. Now Install request is
simply preferred.

This was required because of conditions. The demonstration of this issue
can be done on two packages. Let's have package 'a' and 'b'. There are
three requests of same priority:
* To install 'a'
* To unistall 'b'
* To install 'b' with condition 'a'
The intuitive resolution is that user clearly wants to install 'a' and
not to have 'b'. The third request need not apply as there is more
accurate request to not have 'b'.
The original implementation tries to solve this by maximizing number of
satisfied requests. This has three solution, which is on its own pretty
problematic. The first solution is the intuitive one. Second solution is
to install 'a' as well as 'b'. But the third solution is to not install
any package. This is because third request can be satisfied either by
installing 'b' or by not installing 'a'. All of these solutions are
equivalent in solvers conditions as they all result in only one of the
requests to not be satisfied, thus we have no direct way to hint solver
what to do. What is even worst we even don't know what should be the
correct solution without defining additional resolution rules.

Using the new algorithm the solution for problematic request combination
is simply that we order them using our new defined rules, that is also
the order they are ordered in example. Now we take and resolve one
request at the time. We can clearly satisfy installation of 'a' and thus
first request. We can also satisfy not-installation of 'b' and thus
second request. The third request now can't be satisfied and thus
resulting in just 'a' installed.

Full order rules are described in documentation. Reasoning for them is
also hinted but to be complete there are also alternative orders we
could choose. The reasoning is as follows:
* We need to resolve critical packages first to make sure that all of
  them can be satisfied (so we would not close some combination by
  regular requests).
* The user specified priority has to be abided.
* The requests without condition are preferred as they clearly state
  what should happen. Conditions can have side effect such as forcing
  some specific combination to satisfy given request. This is of course
  highly undesirable as condition should control only if request is
  satisfied not to influence packages specified in condition. Given the
  nature of satisfiability solver this backward injection is just going
  to happen so we instead simply prioritize requests that have no such
  effect.
* Another major change buried in these changes is that Install and
  Uninstall requests for same package no longer raise error. We prefer
  Install requests as a choice. The removal of error is because it was
  arbitrary anyway. There are simple ways Install and Unistall requests
  can be in direct collision without specifying same package name, such
  example being if package 'a' depends on 'b' and there is request to
  install 'a' and to unistall 'b'.
* The last resort order is order of definition is scripts. In the effect
  this is not that important. This affects only requests that have same
  priority, same type (install or uninstall) and both have or not have
  condition. Such requests effectively want the same thing so they
  hopefully should not collide that much in their requests.

Fixed
* environment variable `PKG_UPGRADE` were always set to `1` for package
  `postinst` script no matter if it was package upgrade or not.

Changed
* usage of `example.org` replaced with `application-test.turris.cz` in
  tests

This simply adds these script to dep-package as well as to test-package.
It is nice test for this as one package is newly installed and another
is only upgraded.

The issue here was that control fields in status were updated in
pkg_move function but same and thus invalid check was used in
pkg_scripts later on.
This adds new table with all upgraded packages. This way we check
original state before it is removed from status and pass this info to
subsequent pkg_scripts.

Web example.org now responds with valid HTML site on any URL thus we
have to use different web to get 404 response. We use our own server
that is used in other tests already.

It also turns out that curl changed error messages so instead of
matching exact error message this just tries to match the known minimum.

The usage of this was removed in commit
6e670a7a.

Added
* extra argument `pkg_hash_required` for `Repository` command
* support for version limitation of `Install` and `Uninstall` requests
  in package name (such as `foo (>= 1.0.0)`).

Changed
* Execution is now terminated when there is no hash for package being
  installed in repository index unless `pkg_hash_required` is set to
  `false` for that repository.

Removed
* Extra option `version` for `Install` request. You should append
  version specifier to package name the same way as it is done for
  dependencies.

Fixed
* `ROOT_DIR` not being defined for `hook_postinst` and
  `hook_reboot_required` on replan execution.

The previous expectation that ROOT_DIR is already set is true only if
current execution is reexecution (subsequent execution after replan). In
case of reexecution the ROOT_DIR set is skipped so we have to add it for
postinst as well.

That applies for both postupdate as well as reboot required hook.

This changes how user can specify version limitation for Install request
and adds the same feature for Uninstall as well.

The original method might have been in some ways confusing. Extra field
affects potentially multiple packages but version is commonly specified
only for one specific package request. There is also fully supported way
to specify version limitation in dependency description. This includes
that and reuses the same code.

Also note that code that splits package name from version is improved
here. It should be more reliable now.

This change makes extra option version of Install request obsolete so it
is removed and no longer supported.

Important thing to point out is also that documentation stated that
version extra option can be also table but code never supported that. It
could always have been just single string. That means that we do not
loose any feature set.

This changes default behavior for security reasons. The idea is to fail
if package can't be verified from repository index as there is no hash
supported to use for that. This prevents issue that packages can be
potentially even falsified if index contains hashes unsupported by
updater or even no hash at all.

New extra argument was added to Repository command `pkg_hash_required`.
This is considered in default as set to `true` but it can be
overwritten and set to `false` to disable new behavior.

This new behavior is reported by new feature in updater language:
fatal_missing_pkg_hash

It is possible that if we try to immediately kill process that it won't
make it to exec and that way kill might be caught by check library and
reported as failure. By waiting at least short amount we pretty much
make sure that exec happens and that we are killing sleep process rather
our fork.

With four parallel jobs it is common that connection fails with OCSP
response error. This seems to be an issue with some sort of
rate-limiting in nginx (target web server) on OCSP stamping. It looks
like as 3 is the magic number here for that.

This is no longer valid. All this is now implemented differently or is
going to be shortly.

These documentation is kind of old and although partially correct they
also say a lot of stuff that are no longer true. We should replace them
with more accurate documentation.

Added
* Queue messages for 'upgrade' and 'downgrade' now also print current
  version in square brackets.

Changed
* Default connection timeout for download was extended from one minute
  to ten minutes.

Removed
* Possibility to reboot immediatelly after package installation. Reboot
  after update is deemed sufficient.

Fixed
* Queue messages now state 'upgrade', 'downgrade' and 'reinstall'
  instead of original generic 'install'.

The code used for checking current system status was invalid and in
result whole if condition was being skipped silently. This now enabled
"upgrade", "downgrade" and "reinstall" messages instead of "install".

This also adds current version to upgrades and downgrades of packages.
This is info that is beneficial to know in most cases so it makes no
sense to not show it when we have simple access to it.

This removes immediate reboot possibility from updater.

Original reasoning was to reboot router because update of specific
package broke system so much it can't continue. We never used it. It is
also questionable how such package could break system in a way where
reboot helps. That would have to be kernel module but having some core
systems in module that we would have to do reboot and were unable to
finish update seems like impossible. To finish update we in general need
just filesystem and shell. Existing solution would not work with
theoretical breakage of any of those anyway so it is pretty much useless
feature. Anything this can solve can be also solved by reboot at the end
of update.

This should increase reliability on unstable network connection.

One minute was was way short as it looks like. Ten minutes should be
better, hopefully not the other way around (too long).

We are now focusing primary on English and, in the future, this could be
translated via Weblate. By removing Czech language this script does not
longer prints warning about running in compatible mode

Changed
* pkgupdate's conf.lua now loads scripts with Full security level
  instead of Local
* libupdater is now versioned with release version (there is no API
  compatibility between versions)

Original idea was to limit what scripts placed there can do but in the
end it makes code of those scripts pretty much ugly as it then requires
duplicate code and prevents usage of libraries.

We lost nothing with Full security as Local allows running any arbitrary
shell code.

We use -release because libupdater is technically binary compatible only
with same version of binary tools. This means every build requires new
version of library and vice versa.

This adds additional test for configuration stealing. It checks that
stealing between installed packages works. It also renames original test
to more reflect that it tests only stealing when package is being
replaced.

Fixed
* Warning about cycles for packages providing and at the same time
  conflicting with some other package
* Configure script now checks if uthash is available

The reason is that Conflicts are included as negative dependencies but
to allows flow that package can Conflict and at the same time Provide
specific package (to do effectively replacement) it is implemented as
negative dependency for any version. Version dependencies are satisfied
only by packages of exact name, not by provided packages (for obvious
reasons as Provided packages do not have same versioning scheme).

Fix is that we pass to planning function version limitation of
dependency and plan package only if that is fulfilled by candidate
selected for given group.

We are using uthash.h and we should check if we have it available in
configure.ac.

This is release to only fix build because of missing submodule.

Changed
* Lunit submodule now points to new Github repository

Original repository seems to be no longer accessible. The webside links
to github repo now so this is replacement to that repo.

This improves reporting about action to be performed. Now user is
informed in more standard way if package is new or if it is modification
(and what kind of modification) of installed version.

This extends list of fields checked for reinstall to not only Version
but also to Architecture, LinkSignature, Depends, Conflicts, Provides.

There are two reasons why we want to have these:

First reason applies on Architecture, Depends, Conflicts and Provides.
Those trigger update to get package information in sync with repository.
Updater runs planning against repository so this has no effect but in
the end if someone forgets to bump package but modifies dependencies for
example then we reinstall package anyway.

Second reason to reinstall package applies on LinkSignature and that is
field inserted with hash generated from dynamic linker information
collected for package. When this hash changes then link dependencies
changed and even if version is same we have to reinstall such package as
it most probably won't work with updated dependencies.

As a tinny bonus logs now contain info about version or any other field
if the differ and that way info about the reason to reinstall given
package.

We are grabing scripts output including stderr and because of that we
can't trace childs. Instead we make it so most of our code runs without
fork.

This reverts commit cd44f638.

We can't do this as we are checking output of childs in subprocess and
valgrind taints stderr output with its output.