[Feature suggestion] Ability to manually block specific apps from showing updates and being updated

[Olf0]

There are many reasons for being conservative about upgrading to new SailfishOS releases and some app (and Patch) authors do not mark their RPMs as incompatible with older SFOS releases, plus sometimes apps loose functionality or usability relevant to one, hence it is sometimes desirable to block updates for an app to be displayed and to be installed.
For example, I currently have to ignore four app upgrades on my "production" phone under SFOS 2.2.1, carefully avoiding to upgrade these four when other apps are updated.

Note that an list of blocked apps has to be accessible, to be able to easily find an app for which updating is blocked and unblock it there, at any later time. E.g., YALP Store and Aptoide do this fine, while the F-Droid client app makes finding apps blocked from being updated very tedious (one has to open every app-specific sub-page in "Installed applications").

Side note: Implementing this feature may nicely complement the functionality suggested in issue #13.

P.S.: Manually triggering an installation of the current (or any, per issue #13) version of an app should always be possible (i.e., even if the app is blocked from showing as updateable and the update will not be installed when triggering "Update all"), IMO.

[Olf0]

Actually, if enhancement #13 is implemented, this enhancement becomes more or less a must in terms of usability, otherwise Storeman would permanently offer updates for a deliberately installed, older version of an app.

[mentaljam]

Currently it couldn't be implemented due to the PackageKit issue. Currently triggering update of one package causes update of all available packages. I have a plan to drop PackageKit in favour of libzypp (which can fix the issue).

[Olf0]

Oh, I did not think of this (known) package kit limitation, when writing this feature suggestion, but obviously implementing it with package kit is impossible or extremely hard.

My primary intention was to finally document this feature suggestion, which I had in mind for more than a year, and to point out that implementing enhancement #13 does not make much sense without it.

Switching Storeman from using Package Kit to libzypp sounds like a good plan in general, as libzypp provides a richer feature set, more control, seems to be better maintained etc.
As other, "official" SFOS tools also use libzypp (IIRC, the Jolla Store app and SSU), its future maintenance and availability for SFOS is supposedly ensured by Jolla.

[Thaodan]

Did you reported the issue to packagekit? Some backends have bugs and some are more limited.
On my desktop I don't have the issue you mention.

[Olf0]

As for Storeman the environment SailfishOS provides is relevant and @mentaljam is considering using libzypp directly, it may not be worth the effort investigating potential flaws in packagekit on SFOS, as the goal is to make Storeman work as expected.

[mentaljam]

I've already changed my decision about libzypp. All the same PackageKit is more convenient in case of possible changing or extension of backends. Currently I'm refactoring the OrnPm class which is a wrapper on PackageKit API. After this work finished I would be more confident that it's exact a PackageKit issue. If it is then I'll report an issue.

[Thaodan]

Thanks, maybe try another computer that doesn't use libzypp. Has somene here a suse pc and can try if the bug also affects other packagekit clients like discover?