updater issueshttps://gitlab.nic.cz/turris/updater/updater/-/issues2020-06-15T12:15:06+02:00https://gitlab.nic.cz/turris/updater/updater/-/issues/302Allow (or check if possible) replan on virtual package2020-06-15T12:15:06+02:00Karel KociAllow (or check if possible) replan on virtual packageDoing replan on specially immediate one on virtual package turns out to be pretty useful. The point is that you can just line all package you want to update once before you reexecute updater without needing to select one of them to be th...Doing replan on specially immediate one on virtual package turns out to be pretty useful. The point is that you can just line all package you want to update once before you reexecute updater without needing to select one of them to be the root of three and inserting others as additional dependencies. The reason is that might not be always possible such as if that creates cycle that just can't be broken. With such cycle updater possibly won't allow update as updater is critical package.
I am convince that using virtual packages do not work at the moment with replan as those are ignored when plan is created. This means that with routine cutting away plan in case of replan won't cut it simply because there is not package to cat plan at.https://gitlab.nic.cz/turris/updater/updater/-/issues/240Split package managing to its own separate library2019-07-08T11:02:55+02:00Karel KociSplit package managing to its own separate libraryOperations like single package installation, removal and journal feature should be in its own library. Then having program like opkg-trans (maybe rename it) should help us with low level packages manipulations. At the moment becase opkg-...Operations like single package installation, removal and journal feature should be in its own library. Then having program like opkg-trans (maybe rename it) should help us with low level packages manipulations. At the moment becase opkg-trans depends on heavy libupdater when libupdater is broken because of one of its dependencies (libcurl is prime example) it won't start and won't allow you to fix it. Fixing this without opkg would be nightmare. If we have posix only library and executable that is for this low level packages manipulation it would be much much more easier. This way we could also add at least one more layer of apis to updater.https://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/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/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/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/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 shadowing