Olf0
commented
5 years ago Oh, pardon me, Patchmanager 3.0.55 does all that almost fine!
While the remark, "e.g. per version | rev | cut -f 2 -d ' ' | rev, but not per ssu re" was originally just meant to denote, that version outputs the currently installed SFOS release (in contrast to ssu re, which outputs the release set to upgrade to), PM3 already does most of above suggestion, but really seems to use ssu re instead of version to determine the currently installed SFOS release.
Background: Due to being conservative about upgrading to new SFOS releases on my "production phone", I often observed that something (presumably Jolla's store-client) sets SSU's target release to the new release number, even though I never opened Settings -> Sailfish OS updates (i.e. deliberately avoided doing that), but kept on using Jolla's Store app.
Observations:
Thinking about above issue report filed yesterday, I checked if [ "$(version | rev | cut -f 2 -d ' ' | rev)" != "$(ssu re | rev | cut -f 1 -d ' ' | rev)" ], and yes, the "something" set SSU's target release to 3.0.0.8 (alike it happened before), while version correctly stated 2.2.1.18.
After settings SSU's target release to the currently installed one and rebooting, Patchmanager 3.0.55 handles the compatibility to SFOS releases of web-catalog Patch versions fine, again.
Conclusion: So ultimately this issue has turned into a request to use a different way of determining the currently installed SailfishOS release than something which relies on SSU (as that does not reveal the currently installed SFOS release!).
nephros
Prelude: As some Patch authors fail to update the information, which SailfishOS releases a specific version of a web-catalog Patch is compatible to (even though that version is compatible to newer SFOS releases), users have practically no choice but to enable Patchmanager's Developer mode.
Observed behavior: While the update notifications for web-catalog Patches (per system notification, in Patchmanager's top pulley, in PM's list view of the web-catalog and the Patch specific sub-page there) are working as expected, when a device is on the current SailfishOS release. But when a device has an older SFOS release installed, some web-catalog Patches will have newer versions, which are only compatible to more recent SFOS release(s). One surely does not want to update these Patches. Still Patchmanager 3.0.55 notifies one via all aforementioned ways, that updates are available.
Suggestion to mitigate this: When checking for updated Patches from the web-catalog, compare the currently installed SailfishOS release (e.g. per
version | rev | cut -f 2 -d ' ' | rev, but not perssu re) with the compatibility information of a Patch, for which an update candidate (i.e. newer version) exists, before generating notifications (i.e. do not notify, if the currently installed SFOS release is not supported by the update candidate). IMO, this extra check always shall be active, regardless of Patchmanager's Developer mode being switched on or off.Side note: This suggestion is only about when the update notifications are triggered. The ability to install any version of a Patch, when Patchmanager's Developer mode is active is not at all addressed (and shall be retained).
Tested on a Jolla 1 phone under SailfishOS 2.2.1.18 (while SFOS 3.0.0.8 has been released a few weeks ago) with Patchmanager 3.0.55.
P.S.: As issue reports and feature suggestions implicitly always have a slightly negative touch (as proposing to better something), an explicitly positive statement: Kudos for implementing the multiple, aforementioned ways of notifying that there are update candidates for web-catalog Patches. This is extremely helpful, already.