Inconsistency between `list_upgradable_packages` and `upgrade_package`
Testing the GS plugin I have been bothered by the fact that apks that I manually pinned from cli (so by adding them with a version or by manually installing testing packages with higher versions than in the repositories) are constantly being notified as upgrades in the UI. Even if I click to install the upgrade, the app will do like it is upgrading them, but in reality won't do anything at all.
I found that the reason is inconsistency in between the two functions in apk_database.rs
.
On one side, get_upgrade_changeset
(called from list_upgradable_packages
) first removes checksums from result_mask
and then requests a solve with AVAILABLE
flag set.
On the other side on upgrade_package
the commit is called without flags. Therefore, if a package has a checksum or was pinned to a version, they simply won't be upgraded.
My personal preference would be that list_upgradable_packages
does not go through the extra logic of removing the checksums and looking for packages with AVAILABLE flag. The rationale being that a high-level application should not mess or interact with things that the user purposefully installed to a certain version using CLI. IMHO, the CLI is holy and a GUI should not change what the user did on purpose :D
However, even if there's a disagreement here, I believe that the behavior should be made consistent. As upgrading packages from GS should in principle not overwrite packages pin to a certain version by the user, should a sensible solution be to allow DBus API consumers to set the available flag? That could be done both in list and upgrade functions, and then the plugin decides what to do in each case?
Any thoughts?