updater issueshttps://gitlab.nic.cz/turris/updater/updater/-/issues2019-07-08T11:02:56+02:00https://gitlab.nic.cz/turris/updater/updater/-/issues/230OPKG replacement2019-07-08T11:02:56+02:00Karel KociOPKG replacementWe want to do complete opkg replacement. Current state some what works but is not systematical as we are using one tool for updates and another for explicit packages installation. But simply removing opkg is also not possible as user are...We want to do complete opkg replacement. Current state some what works but is not systematical as we are using one tool for updates and another for explicit packages installation. But simply removing opkg is also not possible as user are used on interactive package installation. The idea is to add new application that would replace opkg in most of the features and wrapper script to simulate opkg.
To support opkg the new command has to support following features:
* [ ] Package installation
* [ ] Package removal
* [ ] Package upgrade
* [ ] Package reconfiguration
* [ ] Listing available and installed packages
* [ ] Listing upgradable packages
* [ ] Listing files belonging to some package
* [ ] Searching packages content
* [ ] Displaying packages info
* [ ] Querying for package status
* [ ] Possibility to download some package
* [ ] Querying for package dependencies
To do that we need to resolve following issues in updater it self:
* [ ] Possibility of considering installed packages
* [ ] Resolve package removal (should we add Uninstall command and in what priority)
* [ ] Lua configuration management (automatically managed file with lua syntax)
* [ ] Updater should use index and userlists cache to make execution faster and less demanding on network connection
Features present in opkg but probably not required by us:
* Multiple architectures support
* Destination names
* `--autoremove` because we are doing that automatically
* Flags settinghttps://gitlab.nic.cz/turris/updater/updater/-/issues/229What package is installed as provided from possibilities is decided alphabeti...2019-07-08T12:48:59+02:00Karel KociWhat package is installed as provided from possibilities is decided alphabeticallyIf we have more than one possible provided candidate for package then we decide
which one we use simply alphabetically by their name. This makes decision stable
but gives us no free hands and only way how to change that is to add `Instal...If we have more than one possible provided candidate for package then we decide
which one we use simply alphabetically by their name. This makes decision stable
but gives us no free hands and only way how to change that is to add `Install`
command but that has side effect that it won't be removed as soon as other
provided candidate is selected. Solution would be to add possibility for packages
to specify their own preference (`Package("pkg", {prefer={"apkg", "bpkg"}})`.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/202Before installing we should check if we have enough space on target drive2021-03-01T15:01:54+01:00Karel KociBefore installing we should check if we have enough space on target driveWe are currently not checking if we have enought space. But we shoudl do that.We are currently not checking if we have enought space. But we shoudl do that.https://gitlab.nic.cz/turris/updater/updater/-/issues/198Store and print requests origin2022-06-06T14:34:32+02:00Karel KociStore and print requests originWe should store request origin (script and line) so we could report errors in configurations with reference. Currently it's impossible to locate from where request came and debugging problems is insanely hard because of that.We should store request origin (script and line) so we could report errors in configurations with reference. Currently it's impossible to locate from where request came and debugging problems is insanely hard because of that.https://gitlab.nic.cz/turris/updater/updater/-/issues/194Package command packages filtering2019-07-08T11:03:01+02:00Karel KociPackage command packages filteringIt should be possible to somehow specify version range the Package command fields should apply to. This should allows us to limit exact configuration reach and directly allows us to specify conflicts between specific packages.It should be possible to somehow specify version range the Package command fields should apply to. This should allows us to limit exact configuration reach and directly allows us to specify conflicts between specific packages.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/7180f486df5fbf8ae3cfe77577bc5dd780d0eaa9https://gitlab.nic.cz/turris/updater/updater/-/issues/167lucheck tests and shadowing2019-07-08T11:03:03+02:00Karel Kocilucheck tests and shadowingWe should also check tests with luacheck. And it might be possible to
differentiate between shadowing on same scope and shadowing variable from upper
scope. We shouldn't be shadowing on same scope, but we want to be able to shadow
upper ...We should also check tests with luacheck. And it might be possible to
differentiate between shadowing on same scope and shadowing variable from upper
scope. We shouldn't be shadowing on same scope, but we want to be able to shadow
upper one.
* [ ] Tests checked by luacheck
* [ ] Allow shadowing only upper scope, not all shadowinghttps://gitlab.nic.cz/turris/updater/updater/-/issues/165For unsatisfied request we should be able to print some diagnostic message why2019-07-08T13:00:31+02:00Karel KociFor unsatisfied request we should be able to print some diagnostic message whyWhen updater can't satisfy some request it is almost cryptic work to find out why.
For development this should be solved when #147 is implemented (it should be
visible from dependency graph), but we should also create way for user to fo...When updater can't satisfy some request it is almost cryptic work to find out why.
For development this should be solved when #147 is implemented (it should be
visible from dependency graph), but we should also create way for user to found out
why something can't be installed. So maybe some diagnostic command that would just
print reasons why some package in some version can't be installed. Or/And print
diagnostic message when request isn't satisfied.https://gitlab.nic.cz/turris/updater/updater/-/issues/137In plan ordering support options order_after and order_before2022-06-06T14:34:08+02:00Karel KociIn plan ordering support options order_after and order_beforeIn configuration file package can have extra options `order_after` and
`order_before`. Support it in plan ordering.In configuration file package can have extra options `order_after` and
`order_before`. Support it in plan ordering.