No app update offered, although available at Openrepos

[Pohli]

Current example: Unit Converter [fork], I got version 2.18-3 installed and version 2.18-5 is available but there's no update option. I can provide screenshots if needed.
I already tried "Refresh cache" and "Reload" from app details page and I also ran "pkcon refresh" before without result.

Jolla Phone with SFOS 3.0.1.11 and Storeman 0.1.6

[mentaljam]

Have you faced the issue lately? Have you tried to update "Unit Converter [fork]" with pkcon when you had reported the issue?

[Olf0]

@Pohli, this might be a consequence of still being on SFOS 3.0.1 in October 2019, while SFOS 3.0.2 (in March 2019), 3.0.3 (in May 2019) and 3.1.0 (in July 2019) have been released meanwhile.

Background:
When checking for updateable packages (i.e. on SFOS: RPMs) with a libzypp based tool (e.g. pkcon or zypper, and consequently also apps using these tools, as the Jolla Store, Storeman or Warehouse), libzypp checks if the Requires dependencies in the spec file can be fulfilled from the enabled repositories (e.g. by installing newly required packages); if not it does not show these updates.
Most often this occurs, when newer versions of system RPMs from Jolla's repositories are required by more recent versions of a community RPM.

In practice, when on an older SFOS release, one might see newer versions of some packages being displayed on Openrepos.net, but not in Storeman etc.

[mentaljam]

@Olf0, your idea about unsatisfied dependencies is really good, I didn't think of it myself. But I've checked harbour-unitconverter.spec. It seems that @a-dekker didn't change the dependencies starting from 2.18-3 (and earlier too).

[Olf0]

Oh, I forgot to mention, that install-dependencies are not only introduced by the Requires statements in a spec file (for Ade's harbour-unitconverter just sailfishsilica-qt5 >= 0.10.9), but also by the compiler / linker for "Shared Objects (.so)" aka "Dynamically Linked Libraries (DLLs)".

For example, look at the output of rpm -qR harbour-unitconverter with Ade's Unitconverter 2.19-1 installed (irrelevant, but for completeness' sake: on an Xperia X with SailfishOS 3.2.1):

ld-linux-armhf.so.3
ld-linux-armhf.so.3(GLIBC_2.4)
libQt5Core.so.5
libQt5Core.so.5(Qt_5)
libQt5Gui.so.5
libQt5Gui.so.5(Qt_5)
libQt5Network.so.5
libQt5Network.so.5(Qt_5)
libQt5Qml.so.5
libQt5Qml.so.5(Qt_5)
libQt5Quick.so.5
libQt5Quick.so.5(Qt_5)
libc.so.6
libc.so.6(GLIBC_2.4)
libgcc_s.so.1
libgcc_s.so.1(GCC_3.5)
libm.so.6
libm.so.6(GLIBC_2.27)
libm.so.6(GLIBC_2.4)
libnemonotifications-qt5.so.1
libsailfishapp.so.1
libstdc++.so.6
libstdc++.so.6(CXXABI_1.3)
libstdc++.so.6(CXXABI_ARM_1.3.3)
libstdc++.so.6(GLIBCXX_3.4)
qt5-qtdeclarative-import-localstorageplugin
qt5-qtdeclarative-import-xmllistmodel
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
sailfishsilica-qt5 >= 0.10.9

I have the impression that new linking-dependencies are regularly introduced by newer Sailfish-SDK versions, thus apps compiled with them will not install (or be offered as an update) on devices with older SailfishOS versions (have not tried to look up, if these things are properly documented by Jolla, e.g. in the SFOS-SDK release notes / changelog or at their SDK documentation pages).

[Olf0]

For example, the recent updates of quite some apps from OpenRepos are not shown on my Xperia X with SailfishOS 3.2.1, because they are compiled with the updated GCC and its newer libraries from the SDK release for SailfishOS 3.3.0 (the SDK version numbers seem to differ from the OS versions; I think it is v2.4, but am too lazy to look this up).
I have seen this happening a few times before, twice I was able to convince the author to recompile in order to let the current version of their apps still run on older SFOS releases, but more often the author does not care ("just update your OS") or there are technical reasons for really requiring a newer software infrastructure (e.g., documented at this PureMaps issue).

[mentaljam]

Maybe the reason is the new dependency on libm.so.6(GLIBC_2.27).

[Olf0]

All in all, I am quite convinced, that the infrastructure Storeman uses (ultimately libzypp / libsolv) does the right thing.
Whenever I experienced these effects, they appeared to be reasonable after some research (although it took me a few years to gather the understanding I briefly described above).

P.S.: You may change the issue title to something more descriptive, especially the word "patch" is irritating in the context of SailfishOS (most will initially think of "Patchmanager Patches", not the "patch level" of an RPM).
What about "No app update offered, although available at Openrepos"?

[Pohli]

Sorry for the late reply. I can't tell for sure that I faced the issue recently but I think so and I'm still on the same old SFOS release. Thanks to @Olf0 for the explanations, sound reasonable. And yes, with the word patch in the title I mean the minor release number, so update title if better understandable.
My plan is to make a factory reset on my Jolla Phone and then update to a recent version but can't say when that will be at the moment.

[Olf0]

[...] I can't tell for sure that I faced the issue recently but I think so and I'm still on the same old SFOS release.

As stated, I do on my [email protected].

[Olf0]

@Pohli, I realise that I missed to ask, where you observed that a newer version of some software installed on your device "is available", but not offered as an update by Storeman.
I always assumed you looked that up at the Openrepos page of the specific software, but maybe you meant "within Storeman"?

Why am I asking?
@mentaljam, since we both switched to an OS version dependent release branches, an OS version dependent release version scheme and corresponding OS release version dependencies defined in the RPM spec file (for Storeman and crypto-sdcard), I see that Storeman currently displays for them on an XperiaX@SFOS3.2.1:

• Storeman
  Installed version: 0.2.2-1~sfos3.2
  Available version: 0.2.2-1~sfos3.3
• crypto-sdcard
  Installed version: 1.3.1-4.sfos321regular
  Available version: 1.3.1-4.sfos340regular

This is basically the same behaviour as discussed for other software in this issue, but becomes better visible by a single version of a software having multiple release versions.
This appeared to be a minor usability issue, because Storeman seemed to just display the wrong release as "Available version" (or simply picks the one with the highest sorting order as "Available version", regardless of all dependencies), but installed the correct one (due to the RPM dependencies defined).

But when updating crypto-sdcard from v1.3.1-2.sfos321regular to v1.3.1-4.sfos321regular per Storeman on this device (XperiaX@SFOS3.2.1) I looked more closely: Storeman updated to the correct version first (v1.3.1-4.sfos321regular), but tried to update to v1.3.1-4.sfos340regular immediately after that, which results in an unmet dependency (as expected: "Error: Nothing provides sailfish-version >= 3.4.0") displayed in Storeman.
As always, Storeman ultimately did it right, v1.3.1-4.sfos321regular was installed after all, but I wonder what triggers the second update (which fails) and why? Maybe (just a wild guess) this is related to the wrong "Available version" being determined and displayed?
When I updated to v1.3.1-2.sfos321regular on this device at the command line, IIRC pkcon update <pkg> did not show this behaviour (i.e., it only tried to install v1.3.1-2.sfos321regular, succeeded and finished).

These observations are not systematically tested yet, I will try to assess the behaviour of Storeman versus pkcon update <pkg> better with the next update of crypto-sdcard (I have one queued) or Storeman on this device with SFOS 3.2.1.
But maybe my current observations are sufficient to determine if something is wrong in Storeman and maybe also what.

P.S.: @Pohli, if you feel comfortable with my suggestion for a better title of this issue (you indicated that), please alter it: It is your issue and this can be done by the issue owner simply hitting the Edit button to the right of the title bar (and cutting&pasting my suggestion, an altered version of it, writing something new etc.); do not miss to hit the Done button after that (which appears to the right when editing an issue title).

[Olf0]

While I missed to watch closely when updating crypto-sdcard 1.3.1-4.sfos321regular to 1.3.1-5.sfos321regular per Storeman on my only device affected ([email protected]), I did so when updating Storeman to 0.2.3-1.sfos3_.2 (per Storeman) today.
Storeman's behaviour is basically the same as described, but the order in which Storeman attempts to install two of the releases with the same version number (but different release numbers) is reversed (compared to above description; it may have been always this way, and above description is simply wrong at this point):

1. Storeman first tried to update Storeman per harbour-storeman-0.2.3-1.sfos3_.4.armv7hl.rpm, which fails (as expected) with an unmet dependency (to some libstdc++.so.6, IIRC).
2. Immediately after that Storeman successfully (also as expected) installs the update per harbour-storeman-0.2.3-1.sfos3_.2.armv7hl.rpm!

As a side note, Storeman now displays for Storeman (note that the available version has changed from the release for SFOS3.3 to the one for SFOS3.4, compared to my former experience):
Installed version: 0.2.3-1~sfos3.2
Available version: 0.2.3-1~sfos3.4
(BTW, why are the underscores visible in the RPM file name not displayed here?)

So, as mentioned before, ultimately "all is good", but I still wonder if senselessly trying to update to the wrong version first is caused by Storeman proper or some underlying software component (pkcon, libzypp etc.).

P.S.: And I still want to carry out a similar update at the command line per pkcon, when there is one available, to see how pkcon (plus maybe also zypper) behaves.

[mentaljam]

but I still wonder if senselessly trying to update to the wrong version first

It's definitely a bug. 0.2.3-1~sfos3.3 and 0.2.3-1~sfos3.4 should not be visible for you as they could not be solved by libsolv and all upon it (rpm, libzypp, packagekit). I will recheck my code to fix this behaviour.

(BTW, why are the underscores visible in the RPM file name not displayed here?

Because this is the way I form the version. mb2 tool (which is used to build packages) replaces tilde to a dot (look here). OpenRepos.net in its turn adds this strange underscore.

[Olf0]

0.2.3-1sfos3.3 and 0.2.3-1sfos3.4 should not be visible for you as they could not be solved by libsolv and all upon it (rpm, libzypp, packagekit).

That is what I assumed.
And while there are surely errors in libsolv (as in any software), it is very well tested and fundamental flaws are unlikely.

It's definitely a bug. [...] I will recheck my code to fix this behaviour.

Thank you.

(BTW, why are the underscores visible in the RPM file name not displayed here?

Because this is the way I form the version. mb2 tool (which is used to build packages) replaces tilde to a dot (look here). OpenRepos.net in its turn adds this strange underscore.

Thanks, these are exactly the kind of pointers I wanted to understand what might be going on here.

P.S. / edit: BTW, Storeman's changing RPM file names (i.e., the release string in them) do not seem to be involved in triggering an incorrect release of the RPM, if an older SFOS version is installed, to be displayed as "available version" and attempted to install it when upgrading this RPM, because Storeman shows the same behaviour with crypto-sdcard.

[Olf0]

Just a new observation, only little analysis so far:
Today I did (try to) update from mount-sdcard-1.7.2-1.sfosXYZ.noarch.rpm to mount-sdcard-1.8.0-1.sfosXYZ.noarch.rpm. The dependency definitions are exactly the same as in earlier versions, still one of my two phones on older SFOS releases shows a different, behaviour than ever before!

• The update went O.K. on an Jolla1 @ SFOS2.2.1 with Storeman 0.0.18, with the minor glitches as described above: I did not see the error notification (but may have just missed it), but as usual, ultimately the right update was installed and Storeman displays then for mount-sdcard: "Installed version: 1.8.0-1.sfos220 / Available version: 1.8.0-1.sfos340"
• But on my XperiaX @ SFOS3.2.1 with Storeman 0.2.5, I see the usual error notification (Error: Nothing provides sailfish-version >= 3.4.0) and no update was installed (this was the first time, it did not work: mount-sdcard-1.7.2-1.sfos321.noarch.rpm was not updated)!
  So I closed Storeman, went to the command line, became root, did a pkcon refresh and started Storeman to try again: The same behaviour (i.e., not updating).
  Then I tried a pkcon download ./ mount-sdcard (because one must omit the version number for all sub-commands, except for the "search" and "install-local" sub-commands), chose the correct version ("2" in this case) and successfully downloaded it.
  Installing it per pkcon install-local mount-sdcard-1.8.0-1.sfos321.noarch.rpm yielded an interesting result: pkcon asked me, if it is O.K. to perform two transactions, updating to "habour-books-1.0.43-xyz (store)" and "mount-sdcard-1.8.0-1.sfos321 (openrepos-olf)". I was very surprised to see an RPM from the Jolla Store (which was correctly identified as updatable) being updated by a pkcon install-local command!
  Ultimately answering with "y" did let pkcon update both RPMs without issues.

One takeaway might be, "The Jolla Store client may interfere with any pkcon command at any time", but on such a high level this insight is not really helpful.

[Olf0]

@Pohli, trying for the third time (see the "P.S."-sections of [1] and [2]):
Please change the issue title to something more appropriate (you once agreed to the need to do that), as this is your issue (i.e., you "own" it)! I (technically) cannot do that. But I have issues finding this issue thread, due to its current, awkward title not "ringing a bell" (for me), each time I look it up.
My suggestion from [1] was: No app update offered, although available at Openrepos

[mentaljam]

I was very surprised to see an RPM from the Jolla Store (which was correctly identified as updatable) being updated by a pkcon install-local command

I surprised that you were surprised XD We have discussed this issue (#96) few years ago (how fast time flies!). For now packagekit updates all packages on any kind of transaction.

For my shame, I still have not searched for related issues on packagekit repositories and have not reported a bug.

[Olf0]

I surprised that you were surprised XD We have discussed this issue (#96) few years ago (how fast time flies!).

Oh, your memory is way better than mine: more than two years, that appears to be "ages ago" for me. ;-)

For now packagekit updates all packages on any kind of transaction.

True, I was just surprised by the "really any" aspect: Specifically that an install-local sub-command installs RPMs fetched from the internet.
But "Yes", this seems to be a logical consequence of some fundamental issue in packagekit.

[Olf0]

@mentaljam: Sorry for expressing my surprise about the "really any updatetable RPM may become updated, when installing or updating RPMs per pkcon or Storeman" so intensively, that we both became sidetracked.

The main point in my message on 1 June 2021 was:
Our versioning scheme for multiple SFOS releases seems to have ceased to work with Storeman. I.e., Storeman still complains about not being able to install the version of the software with the highest version number (for the newest SailfishOS), but now it does not ultimately install the right update. I observed this when trying to update to the recent versions of Storeman and crypto-sdcard (at the beginning of June and once more, a few weeks ago).

[Olf0]

As an addition to my last comment:
A few day ago I used pkcon install-local again and forgot to update other apps via Storenman before that (now being aware that this happens per pkcon then) on my [email protected].
Among other packages, pkcon nicely updated Storeman from harbour-storeman-0.2.7-* to harbour-storeman-0.2.8-1~sdk3.2.1.20.armv7hl. So that worked well per pkcon, I wonder if why that did not seem to be case when updating per Storeman; next time I will try that again.

Side note / off topic: While the binaries of the armv7 builds of Storeman 0.2.x are all slightly above 300 KBytes, the i486 builds jumped from ≥ 300 KBytes for versions up to 0.2.7 to ~ 3 MBytes for version 0.2.8!

[Olf0]

The main point in my message on 1 June 2021 was: Our versioning scheme for multiple SFOS releases seems to have ceased to work with Storeman. I.e., Storeman still complains about not being able to install the version of the software with the highest version number (for the newest SailfishOS), but now it does not ultimately install the right update. I observed this when trying to update to the recent versions of Storeman and crypto-sdcard (at the beginning of June and once more, a few weeks ago).

An excursion on this topic was performed by Rubdos at FSO ff. with a really well written spec file etc., but ultimately it still does not work (anymore).

[Olf0]

Side note / off topic: While the binaries of the armv7 builds of Storeman 0.2.x are all slightly above 300 KBytes, the i486 builds jumped from ≥ 300 KBytes for versions up to 0.2.7 to ~ 3 MBytes for version 0.2.8!

This was likely the same effect as described in sailfishos-applications/filecase#45 for SFOS 2.2.0 - 3.0.1 and likely earlier versions, too.