updater issueshttps://gitlab.nic.cz/turris/updater/updater/-/issues2023-05-30T14:32:49+02:00https://gitlab.nic.cz/turris/updater/updater/-/issues/254Updater seems to have problems with links2023-05-30T14:32:49+02:00Karel KociUpdater seems to have problems with linksCurrent version of updater (v60.4.6) has problems with links. It is unable to replace them if it encounters them. This is probably because it recognizes them as directories and tries to write data to them. This of course fails if target ...Current version of updater (v60.4.6) has problems with links. It is unable to replace them if it encounters them. This is probably because it recognizes them as directories and tries to write data to them. This of course fails if target is not a directory or does not even exists. We should expect that there can be something like link and if it is valid link then we should follow it. If there is invalid link then we should replace it with new directory (or should we create target directory instead?).
This might be fixed by not using busybox so this issue should be revisited when we drop busybox.https://gitlab.nic.cz/turris/updater/updater/-/issues/228Request for conflicting packages is resolved randomly2019-07-08T11:02:57+02:00Karel KociRequest for conflicting packages is resolved randomlyIf we have requests of same priority for conflicting packages then we choose one
of those in random. In wost case scenario we could be constantly switching between
those packages.
The solution is to add one additional parameter and that...If we have requests of same priority for conflicting packages then we choose one
of those in random. In wost case scenario we could be constantly switching between
those packages.
The solution is to add one additional parameter and that is order of introductions
of requests. If request is introduced before some other request then we should
prefer it. The implementation can be done using binary search algorithm to always
assume first half of internal and if that is not possible then we can divide it
and do the same recursively.https://gitlab.nic.cz/turris/updater/updater/-/issues/224Errors from pacakges should not be reported as errors from updater it self2019-07-31T11:07:55+02:00Karel KociErrors from pacakges should not be reported as errors from updater it selfIf package's script fails then it's reported as Updater's error same as if updater
fails. This confuses users and elevates small in single package to system level
errors.
Also maybe don't report packages errors as errors but as warning...If package's script fails then it's reported as Updater's error same as if updater
fails. This confuses users and elevates small in single package to system level
errors.
Also maybe don't report packages errors as errors but as warning (exception should
probably be critically requested packages).https://gitlab.nic.cz/turris/updater/updater/-/issues/221When preinst of critically requested package fails then we should not continue2019-07-08T11:02:58+02:00Karel KociWhen preinst of critically requested package fails then we should not continueCurrently if critically requested package's preinst script fails we just ignore it
as any other package and repost error later on. We should abandon the transaction
in such case.
We really don't have too much critical package with prein...Currently if critically requested package's preinst script fails we just ignore it
as any other package and repost error later on. We should abandon the transaction
in such case.
We really don't have too much critical package with preinst scripts so it's not
exactly important. But we should do that some time in future nevertheless.https://gitlab.nic.cz/turris/updater/updater/-/issues/216On replan when we fail with error we do reexecute2019-07-08T12:54:20+02:00Karel KociOn replan when we fail with error we do reexecuteWhen we exit with error but one of packages requested replan then we do reexec.
This is some what weird and we shouldn't probably be doing that.When we exit with error but one of packages requested replan then we do reexec.
This is some what weird and we shouldn't probably be doing that.https://gitlab.nic.cz/turris/updater/updater/-/issues/214Provides and Conflicts with specific version2019-07-08T11:02:59+02:00Karel KociProvides and Conflicts with specific version`Provides` and `Conflicts` can have version specified same as `Depends` field for example. We are
not handling that currently.
But also it's almost no where to be found in OpenWRT.`Provides` and `Conflicts` can have version specified same as `Depends` field for example. We are
not handling that currently.
But also it's almost no where to be found in OpenWRT.https://gitlab.nic.cz/turris/updater/updater/-/issues/210block_split splits comments as separate blocks which is invalid2019-07-08T11:02:59+02:00Karel Kociblock_split splits comments as separate blocks which is invalid`block_split` splits following code to three blocks which is invalid:
```
Package: test
Description: This is description
With more lines and some spaces
Package: other
Description: Just another package
```
Currently this behaviour is...`block_split` splits following code to three blocks which is invalid:
```
Package: test
Description: This is description
With more lines and some spaces
Package: other
Description: Just another package
```
Currently this behaviour is hidden simply because invalid block has no `Package:`
field and so it's ignored. But that doesn't mean that its valid.https://gitlab.nic.cz/turris/updater/updater/-/issues/192When configuration file is removed we should also remove *-opkg files2019-12-03T14:34:39+01:00Karel KociWhen configuration file is removed we should also remove *-opkg files*-opkg files are created when we install configuration file and old version is
modified from original.*-opkg files are created when we install configuration file and old version is
modified from original.https://gitlab.nic.cz/turris/updater/updater/-/issues/187We should be consistent in combination of critical packages and replanning2022-06-06T14:34:28+02:00Karel KociWe should be consistent in combination of critical packages and replanningWe should ensure that critical packages are installed in consistent way, so we
shouldn't update them their dependencies if we are going to replan. This can
result in broken essential software like DNS resolver if library is updated and
t...We should ensure that critical packages are installed in consistent way, so we
shouldn't update them their dependencies if we are going to replan. This can
result in broken essential software like DNS resolver if library is updated and
then replan is done.
* [x] Packages causing immediate replanning should be planned as soon as possible
* [ ] If package causes immediate replan and isn't critically requested we should
print warning.
* [ ] Implement replan "immediate" and "finished". And document that "immediate"
shold be used only for updater it self.
This should solve problem with nuci replanning in the middle of unbound update.
After resolving this, revert https://gitlab.labs.nic.cz/turris/openwrt/commit/7180f486df5fbf8ae3cfe77577bc5dd780d0eaa9