Does Storeman not find its own updates?

[Olf0]

SailfishOS VERSION (Settings → About product → Build): 3.2.1, likely all supported versions 3.1.0 to 4.5.0

HARDWARE (Settings → About product → Manufacturer & Product name): Xperia X, likely hardware independent

Storeman VERSION (Storeman → <Top pulley> → About Storeman): 0.3.2

BUG DESCRIPTION

Storeman does not find its own updates, i.e., it does not offer its newer versions as update candidates to install. I currently have v0.3.2 installed on this older device, and there have been two newer releases published as of 2023-03-18 in its own OBS sub-repository: 0.3.3 and 0.3.4

STEPS TO REPRODUCE

1. Install an older Storeman release from GitHub's releases page of Storeman.
2. Check that its "Check for self-updates" switch is on in Storeman's settings, see https://github.com/storeman-developers/harbour-storeman/blob/devel/qml/pages/SettingsPage.qml#L180-L185
3. See that it does not find its updates.

ADDITIONAL INFORMATION

Maybe I broke something when adapting all the links (primarily by v0.2.12), but I cannot see what!

1. The URL and repo name is correct and consistent, see
   • https://github.com/storeman-developers/harbour-storeman/blob/devel/qml/pages/SettingsPage.qml#L180-L185
   • ssu lr displays this repo as first user repo.
   • https://github.com/storeman-developers/harbour-storeman/blob/devel/src/ornpm.cpp#L28
   • The repo address is correct, see e.g.: https://repo.sailfishos.org/obs/home:/olf:/harbour-storeman/4.3.0.15_aarch64

What I completely fail to understand is what src/ornrepo.cpp is for and does: https://github.com/storeman-developers/harbour-storeman/blob/devel/src/ornrepo.cpp
I also wonder about the empty pair of braces { } at its end?!? Is that correct?

The same applies to the corresponding header file (no clue): https://github.com/storeman-developers/harbour-storeman/blob/devel/src/ornrepo.h
What is the alias for and how does it work?

Maybe this was never working, i.e., maybe this bug exists since the switch to OBS-based builds with Storeman 0.2.9?!?

P.S.: I still have to determine how to enable the debug output (and where it writes to) to see https://github.com/storeman-developers/harbour-storeman/blob/devel/src/ornpm.cpp#L118-L119
When started at the command line as regular user by execution harbour-storeman, I usually see a couple of warnings and errors, but they always were there (I opened a bug report for that years ago which was closed, because these errors and warnings were deemed "normal").

• But often when triggering a repositories refresh manually (Repositories → [Top pulley] Refresh cache) an endless chain of launcher notifications (literally: it does not stop until Storeman is closed) pops up:
  An error occurred
Failed to obtain authentication.
• When Storeman was started at the command line, concurrently a long (maybe also endless; I usually stopped Storeman after many 10 such lines) chain of debug output messages is printed at the terminal:
  [D] unknown:0 - Specified Desktop file does not exist ""
  Note that I was successfully logged in at OpenRepos via Storeman all the time; the "authentication" mentioned seems to address something different (OpenRepos' API auth?)

P.P.S.: As a dirty workaround, I consider re-submitting Storeman to SailfishOS:Chum again. While this may trigger social conflicts (again), it would make Storeman updatable again vie, e.g., the SailfishOS:Chum GUI application.

I also considered switching the update OBS repo from a personal one to SailfishOS:Chum, which would free me from timely maintenance of the personal OBS repo after a new SailfishOS releasee. But then the Storeman-Installer has to enable the SailfishOS:Chum OBS-repo, which need some technical coordination so that the SailfishOS:Chum GUI app does not complain about other apps also handling this repo (it may work just fine, though). One would have to model all cases with both installers and the applications proper being installed or removed in any order. Nevertheless, this bug has to resolved for any of these considerations.

[Olf0]

@nephros, I am lost on this one (and not-updating is a serious bug): I checked my configuration changes as thoroughly as I can and recently documented all relevant information (IMO exhaustingly) in the original issue report above. I would appreciate very much if you take a closer look at this, when you can spare the time.

[nephros]

I haven't looked at the code yet, but can reproduce:

harbour-storeman-0.3.2-1.11.1.jolla.aarch64

is installed. Neither storeman nor pkcon find updates.

From the OBS repo is not surprising, as it is NOT in the list of user repos in ssu lr.

[nephros]

I also see a 'Storeman OBS repository' in Storeman itself (under Repos) but it is not clickable as opposed to (all?) other repos listed there.

And it cannot be found on the web page.

[nephros]

Manually adding the obs repo via ssu ar, refreshing does fix the issue.

From here it looks like either 0.3.2, its installer, or something removes the repo, hence no updates.

[nephros]

WHY is there a 'Storeman OBS Repo' listed when no part of the system knows of it?

Edit: answer: because it's inserted into the model whether or not it's in the list gotten from ssu, as long as it is not disabled:

115-    }
116-    qDebug() << "System has" << repos.size() << "ORN repositories";
117-
118-    qDebug() << "Getting the Storeman OBS repository";
119:    repos.insert(OrnPm::storemanRepo, !disabled.contains(OrnPm::storemanRepo));
120-
121-    qDebug() << "Getting the list of installed packages";
122-    auto spool = pool_create();
123-    auto srepo = repo_create(spool, OrnConst::installed.toLatin1().data());

[nephros]

(sorry for the spamming, SFOS browser can't edit GH comments)

That known/unknown OBS repo may also be is the reason for the 'couldn't find the specified repository' message that always pops up on refresh.

Edit: confirmed by using context menu->refresh on it.

[nephros]

I assume something is amiss with all the 'either use an openrepos-foo OR hardcoded Storeman update repo name' logic.

Can't investigate this weekend tough.

[Olf0]

I haven't looked at the code yet, but can reproduce:

harbour-storeman-0.3.2-1.11.1.jolla.aarch64

is installed. Neither storeman nor pkcon find updates.

I never tried the latter: Now I did with the same result, There is no update candidate for harbour-storeman-0.3.2-1.8.1.jolla.armv7hl!?!

From the OBS repo is not surprising, as it is NOT in the list of user repos in ssu lr.

That is definitely not true for my devices and should be "impossible":

1. Storeman Installer sets this repo, if not already set in its %post scriptlet and never removes it.
2. Storeman sets this repo, if not already set in its %post scriptlet.
3. ssu lr | less displays the harbour-storeman-obs repo as the first entry of the user repos on my device.

I also see a 'Storeman OBS repository' in Storeman itself (under Repos) but it is not clickable as opposed to (all?) other repos listed there.

Oh, I never realised that. While this repository entry is not "clickable" in the sense of "openable", it does have a context menu in which it can be disabled. But this repository already gets some special treatment, because its context menu does not offer "Refresh cache", "Disable" and "Remove" as for all other repositories, but only "Refresh cache" and "Disable". Only when it is disabled (does work fine, see ssu lr), the context menu shows "Enable" for it, but not "Enable" and "Remove" as for all other disabled repositories.

So this is O.K., although the entry "Check for self-updates" in Storeman's settings does exactly the same: Enable and disable the harbour-storeman-obs repository. Consequently the only function the entry "Storeman OBS repository" in the repo list offers uniquely is "Refresh cache". This fine, and I am glad that your remark triggered me to check that all this works well and as intended: It does.

And it cannot be found on the web page.

¿Which web-page?
It is there, see https://build.merproject.org/project/show/home:olf:harbour-storeman
And its download repository appears to be (& to me) looking as it should, see for example https://repo.sailfishos.org/obs/home:/olf:/harbour-storeman/4.5.0.19_aarch64/
also via its alternative DNS name, see https://repo.merproject.org/obs/home:/olf:/harbour-storeman/4.5.0.19_aarch64

Manually adding the obs repo via ssu ar, refreshing does fix the issue.

Really?!? Not for me. As denoted before the repo is set correctly by the Storeman Installer and Storeman for me and is not removed, unless Storeman is removed. I have tested that many times. Can you please re-test, because the different outcomes at this point is strange.

By "the issue" you still mean the original one; i.e., now a pkcon update harbour-storeman works fine for you rsp. Storeman shows an own update as an update candidate?

From here it looks like either 0.3.2, its installer, or something removes the repo, hence no updates.

As stated: I cannot reproduce this and never saw this in the past while testing.

WHY is there a 'Storeman OBS Repo' listed when no part of the system knows of it?

True, that behaviour is confusing. Likely Petr (mentaljam) did not consider (neither did I, up to now) the situation you experience, because having no harbour-storeman-obs entry in SSU's repo list (neither enabled nor disabled) should never occur, as long Storeman is installed. It may make sense to take and display this repository's status from SSU, so one can at least see that it is not there at the GUI; but that is primarily beautification, as ssu lr does the job, and bit off-topic WRT this issue here.

Edit: answer: because it's inserted into the model whether or not it's in the list gotten from ssu, as long as it is not disabled:

… and when it is disabled it still is handled specially, presumably be some piece code elsewhere.

(sorry for the spamming, SFOS browser can't edit GH comments)

If you have a license Alien Dalvik / "AAS", do use Firefox! The SFOS browser is still unusable and featureless, just as Jolla Mail is compared to K9 Mail. This will never change (for many reasons), especially now that AAS is Jolla's primary product and SFOS is basically relegated to a mass testing platform for AAS betas; consequently the Jolla apps seem to be in maintenance mode since 2022 (i.e., after the SFOS 4.4.0 release).

That known/unknown OBS repo may also be is the reason for the 'couldn't find the specified repository' message that always pops up on refresh.

… which I never saw before, because I always had the harbour-storeman-obs entry in SSU's config. So before proceeding, we have to determine what went wrong for you, because I never experienced that and never received a bug report indicating that. Note that the Storeman Installer would not work, if it does not configure the harbour-storeman-obs repo correctly (for SSU), refreshes it successfully and lastly installs Storeman from it: This has worked fine for thousands of users with no complaints.

Edit: confirmed by using context menu->refresh on it.

Well, this consequence of the harbour-storeman-obs entry missing in SSU's config is fine and as it should: All pkcon errors triggered by Storeman shall be displayed as such messages or notifications on the GUI.

I assume something is amiss with all the 'either use an openrepos-foo OR hardcoded Storeman update repo name' logic.

My assumption is that I did miss something when converting the mentaljam-obs entry pointing to Petr's personal repo at the SailfishOS-OBS to harbour-storeman-obs pointing to mine. You may do such trivial things as grepping for "mentaljam" in the whole source tree (I did this two times, but may be "too blind to see" something relevant): "mentaljam" should now solely occur in text strings for output (e.g., on the "About" QML page).

Can't investigate this weekend tough.

Take your time (and do that on a laptop, notebook or desktop PC 😉), I am aware of this issue for many, many months and only recently found the time to document it properly and concurrently to re-evaluate it; a few weeks more or less does not matter at all. As usual, no user has opened a bug report, yet.

[nephros]

Hm, no idea how to track down when the repo was removed.

While /var/log/zypp/history has 'rremove' events, it seems such event is logged even when simply refreshing repos.

There are no useful entries there for adding a repo as far as I can see.

I did try again:

1. have storeman 0.3.2-1.11.1.jolla aarch64 installed
2. Have NO harbour-storeman-obs repo configured
3. --> no self-updates found
4. Manually add repo: ssu ar harbour-storeman-obs https://repo.sailfishos.org/obs/home:/olf :/harbour-storeman//4.4.0.72_aarch64
5. Restart Storeman
6. --> update to harbour-storeman-0.3.4-1.14.1.jolla.aarch64 is offered.

[nephros]

This is the scripts section of the 0.3.2 RPM:

postinstall scriptlet (using /bin/sh):
# The %post scriptlet is deliberately run when installing *and* updating:
ssu_ur=no
ssu_lr="$(ssu lr | grep '^ - ' | cut -f 3 -d ' ')"
if printf %s "$ssu_lr" | grep -Fq mentaljam-obs
then
ssu rr mentaljam-obs
rm -f /var/cache/ssu/features.ini
ssu_ur=yes
fi
if ! printf %s "$ssu_lr" | grep -Fq harbour-storeman-obs
then
ssu ar harbour-storeman-obs 'https://repo.sailfishos.org/obs/home:/olf:/harbour-storeman/%(release)_%(arc
h)/'
ssu_ur=yes
fi
if [ $ssu_ur = yes ]
then ssu ur
fi
# BTW, `ssu`, `rm -f`, `mkdir -p` etc. *always* return with "0" ("success"), hence
# no appended `|| true` needed to satisfy `set -e` for failing commands outside of
# flow control directives (if, while, until etc.).  Furthermore on Fedora Docs it
# is indicated that only the final exit status of a whole scriptlet is crucial:
# https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_syntax
postuninstall scriptlet (using /bin/sh):
if [ $1 = 0 ]  # Removal
then
ssu rr harbour-storeman-obs
rm -f /var/cache/ssu/features.ini
ssu ur
fi

[nephros]

Maybe the failsafe fix would be to add and enable the storeman repo when the selfupdate settings switch is toggled (instead of just enabling it)?

[Olf0]

This is the scripts section of the 0.3.2 RPM:

This looks fine and is unaltered ever since (i.e., in 0.3.3 and 0.3.4).

Puzzled.

Does ssu lr | grep '^ - ' | cut -f 3 -d ' ' output the list of repository names on your device? Maybe Jolla has subtly altered a format / interface, again (they love that).

Maybe the failsafe fix would be to add and enable the storeman repo when the selfupdate settings switch is toggled (instead of just enabling it)?

I do not want to "repair" an issue with a hammer, which I do not comprehend at all:

• I have the harbour-storeman-obs repository enabled in SSU, but Storeman and pkcon do not find an update candidate.
• On your device the harbour-storeman-obs repository is not added (or immediately removed by something) when installing Storeman, but an update candidate is found as soon as you manually add it.

WTF!

[nephros]

Yes, the output looks fine.

The only thing I have encountered that does not do an update even though it is there is a vendor change.

Does zypper let you update?

[nephros]

I don't know why the rm features.ini and ssu ur combination is necessary but:

1. There is a possibility that features.ini does not exist when ssu ar is run in the %post scriptlet. It's when the mentaljam repo is present, but the obs one is not. I have no idea whether this is bad though.

2. This seems to suggest killing ssud should be done when dealing with the features.ini cache: https://github.com/sailfishos/ssu/pull/3/files

[Olf0]

The only thing I have encountered that does not do an update even though it is there is a vendor change.

Me too, but as I do not set a vendor in the spec file, I assumed that this cannot be the case here.

This was an excellent suggestion:

Does zypper let you update?

$ zypper up harbour-storeman
There is an update candidate for 'harbour-storeman', but it is from a different vendor. Use 'zypper install harbour-storeman-0.3.4-1.16.1.jolla.armv7hl' to install this candidate.

So I did
$ zypper download harbour-storeman-0.3.4-1.16.1.jolla.armv7hl
and
$ rpm -qi /var/cache/zypp/packages/harbour-storeman-obs/armv7hl/harbour-storeman-0.3.4-1.16.1.jolla.armv7hl.rpm
which shows (among other info)
Vendor : meego

Oh yes, sure, now I remember that the SailfishOS-OBS stubbornly sets the Vendor to meego. That explains what I experience.

My ideas how to avoid such accidents:

• Set the vendor to meego in Storeman's spec file, so this becomes the vendor for all distribution channels.
  Edit: Done via commit e3078c8.
• Try to set the Vendor empty in Storeman Installer's spec file, as it shall present itself as an update candidate for older Storeman releases (< 0.2.9), which all were vendor-less.
  Edit: This seems to be impossible at the SailfishOS-OBS, because the Vendor cannot be unset, neither via %undefine vendor nor via Vendor: followed by nothing in front of the line break, regardless if applied in a spec file or an OBS project configuration (prjconf file).

Does that sound O.K.?

[Olf0]

I don't know why the rm features.ini and ssu ur combination is necessary but:

Neither do I; something I have not researched and likely will not, because ssu is niche software and so is know-how about it. It was there, consistently for all repo removals by ssu rr. Usually Petr knows what he is doing, but at few places he just copied stuff. This construct is also present in the SailfishOS:Chum GUI app.

1. There is a possibility that features.ini does not exist when ssu ar is run in the %post scriptlet. It's when the mentaljam repo is present, but the obs one is not. I have no idea whether this is bad though.

AFAIR from my install tests a year ago, it does not matter: It is a cache file and becomes rebuilt, if missing.
Also the mentaljam-obs repo did only distribute Storeman up to ca. February 2022. You sure did not have it on your device.

2. This seems to suggest killing ssud should be done when dealing with the features.ini cache: https://github.com/sailfishos/ssu/pull/3/files

I looked at this before and still do not understand it. As usual sailors do not write comments or commit messages, except for "Fixes JB #xxxxxx" (referencing a "Jolla bug" in their internal bug tracker). Jolla has never been a Free Software company as SuSE or RedHat and will never be one, because they fiercely do not want that.

[nephros]

Aha!

OBS does set the meego vendor, but thechum (and chum:testing) repos do not, they use chum (macro set in project config).

So any rpm coming from chum will not update to any non-chum-built one and vice versa.

I guess that explains the phenomenon of this issue.

About my missing repo, it's probably not worth pursuing, I may have removed that manually at one point, I can't be sure.

(Or maybe the Storeman 'empty repo detection' removes it under certain circumstances if the ssu system presents it as empty for some reason.)

[Olf0]

[The SailfishOS-]OBS does set the meego vendor,

… because Jolla configured that as default.

but thechum (and chum:testing) repos do not, they use chum (macro set in project config).

Yes, they override it via prjconfig entry, see here for details.

So any rpm coming from chum will not update to any non-chum-built one and vice versa.

Not exactly: One can override both defaults via spec file.

Thus my considerations to unify on one specific vendor setting for different distribution channels.
IMO "injecting" Vendor is a big hurdle for software which also is built elsewhere, e.g., by GitHub's CI and then distributed at e.g., OpenRepos. Hence these considerations are also applicable to, e.g., Patchmanager.

I guess that explains the phenomenon of this issue.

For my issue: Yes.

---

About my missing repo, it's probably not worth pursuing, I may have removed that manually at one point, I can't be sure.

I wondered what the two "have"s in points 1 and 2 of this comment of yours meant: Did you reinstall (this was my initial interpretation) or was that the status quo?

(Or maybe the Storeman 'empty repo detection' removes it under certain circumstances if the ssu system presents it as empty for some reason.)

IMO, this has to be manually triggered and confirmed by the user, hence it should not "just happen".

[Olf0]

BTW, WRT this message of yours:

3. This seems to suggest killing ssud should be done when dealing with the features.ini cache: https://github.com/sailfishos/ssu/pull/3/files

I looked at this before and still do not understand it.

I do understand it, now (as already a few times before, only to forget about it soon after):

• The top of this commit shows the %post scriptlet of the spec file for ssu, which is called after installation and every update.
• After updates it should be ensured that the old ssud is not still running, because a new one was freshly installed.
• This change moves the killing of a prior ssud to the extant oneshot unit ssu-update-repos.
• This oneshot unit decouples the probably lengthy execution of ssu ur from the scriplet it calls it (so the sciptlet and hence rpm can finish independently of the ssu ur run). Note that this aspect was not altered by this commit.
• The former function of this oneshot unit ssu-update-repos is moved to the first of the five new scriptlets (the %transfiletriggerin one), but instead of touching all *.ini files in %{_datarootdir}/%{name}/board-mappings.d/ it now touches all freshly installed *.ini files in %{_datarootdir}/%{name}, because the freshly deployed files carry the timestamp(s) while packaging them.
• The three new %transfiletriggerun scriptlets simply remove SSU's caches for the corresponding configuration directories %{_datarootdir}/%{name}/features.d/, %{_datarootdir}/%{name}/board-mappings.d/ and %{_datarootdir}/%{name}/repos.d/. Note that these three scriptlets do not trigger the aforementioned oneshot unit, hence do not need the ssud to be restarted. (This point answers your question with "No", because we also just remove the feature cache via rm -f /var/cache/ssu/features.ini.)
• Only deploying new *.ini files (see the first scriptlet, the %transfiletriggerin one) and removing SSU's data completely (see the last scriptlet, the %transfiletriggerpostun one) logically require an old ssud to be killed.
• Mind that the order of the scriplet execution on updates is a bit complex, especially if one takes all the %trigger* scriplets into account.

---

Still I would appreciate very much if someone explains your original question, …

[…] why the rm features.ini and ssu ur combination is [deemed] necessary […]

… after removing a repository via ssu rr (instead of only executing ssu ur afterwards).

[nephros]

About my missing repo, it's probably not worth pursuing, I may have removed that manually at one point, I can't be sure.

I wondered what the two "have"s in points 1 and 2 of this comment of yours meant: Did you reinstall (this was my initial interpretation) or was that the status quo?

Ever since becoming aware of this issue (by your mention in the comment above), my main device has had 0.3.2-1.11.1.jolla aarch64 installed - from when or how exactly I'm not sure.

I did not downgrade, reinstall or otherwise alter the installation of Storeman that was already there.
I might have reinstalled (through either Storeman-Installer, or a manually downloaded RPM) after the last SFOS update (to 4.4.0.72, as that is what I'm still running on the Xperia10iii).

So I was genuinly affected by this issue of updates not being detected (though for a different reason - missing repos vs vendor change - as it turns out).

I did confirm though that this installed version 0.3.2 had vendor meego, as did the updates offered after manually adding the obs repo.

[Olf0]

Thank you for the clarification!
_{Although I do not like its content, but that is rather my fault or whatever goes wrong: I will download and install 0.3.2 form OBS and see what it does, when time allows for that.}

[nephros]

My ideas how to avoid such accidents:

• Set the vendor to meego in Storeman's spec file, so this becomes the vendor for all distribution channels.
• Try to set the Vendor empty in Storeman Installer's spec file, as it shall present itself as an update candidate for older Storeman releases (< 0.2.9), which all were vendor-less.

Does that sound O.K.?

I'm not familiar enough with the "RPM publication" history of Storeman to say for sure.

Were there at any point e.g. chum vendored RPMs of Storeman? Or any other vendor besides meego and "nothing"?

Because if there were, installed versions would "forever" stay at their original version if any updates were vendored meego (or anything else), right?

[Olf0]

The answers to your three questions are: "Yes", "Only chum, but three different vendor strings is two too many" and "Yes", unfortunately. But I can see no other way out than to statically set the vendor for all builds (rsp. build locations) and distribution channels to the same value; better now than later or never. So, yes some people will not be able to update without reinstallation, …

But OTOH, the last two SailfishOS releases (4.4.0 and 4.5.0) and IIRC even their point releases removed Storeman (and the SFOS:Chum GUI app alike). So users regularly have to reinstall any way. 😁

I see no choice but to go for the most distributed vendor name, which clearly is meego for Storeman ≥ 0.2.9; versions before that require a reinstallation of Storeman to update to Storeman ≥ 0.2.9 due to the switch from being distributed via OpenRepos to the SailfishOS-OBS.

P.S.: The same applies to Patchmanager and my corresponding, open (and unreviewed, BTW 😉) PR: Here chum is the most common denominator IMO, even though some versions at OpenRepos and all at GitHub were vendor-less.

[nephros]

I was wondering if there was a way to let Storeman allow vendor changes at least for self-updates.

And indeed even pkcon apparently can do that:

pkcon search --filter installed patchmanager
Searching by details
Starting
Refreshing software list
Finished
Installed       patchmanager-3.2.7+obs.20230224125628.21.gd2f0918-1.1.1.jolla.aarch64 (installed)       Allows to manage Patches for SailfishOS
nemo@PGXperiiia10:~ $ pkcon resolve patchmanager
Resolving
Installed       patchmanager-3.2.7+obs.20230224125628.21.gd2f0918-1.1.1.jolla.aarch64 (installed)       Allows to manage Patches for SailfishOS
Available       patchmanager-3.2.8-1.1.1.jolla.aarch64 (sailfishos-chum)        Allows to manage Patches for SailfishOS
Available       patchmanager-3.2.7-1.aarch64 (openrepos-Patchmanager)           Allows to manage Patches for SailfishOS
nemo@PGXperiiia10:~ $ pkcon update
Getting updates
Finished
No packages require updating to newer versions.
nemo@PGXperiiia10:~ $ pkcon update patchmanager
Resolving
Querying
Finished
Fatal error: There is no update candidate for patchmanager-3.2.7+obs.20230224125628.21.gd2f0918-1.1.1.jolla.aarch64

nemo@PGXperiiia10:~ $ pkcon install patchmanager
Resolving
Testing changes
Finished                                                                                                                                                                                                                                                                                                                                                            
The following packages have to be installed:
 patchmanager-3.2.8-1.1.1.jolla.aarch64 Allows to manage Patches for SailfishOS
Proceed with changes? [N/y] y

So the PackageKit install action can perform a vendor change. (The OpenSuSE doc page on vendor changes says this as well, albeit a bit "hidden".)

So one solution could be to make Storeman not use the upgradePackage but rather the installPackage call for updates.

• https://www.freedesktop.org/software/PackageKit/gtk-doc/Transaction.html#Transaction.UpdatePackages
• https://www.freedesktop.org/software/PackageKit/gtk-doc/Transaction.html#Transaction.InstallPackages
• https://github.com/storeman-developers/harbour-storeman/blob/devel/src/ornpktransaction.cpp#L61
• https://github.com/storeman-developers/harbour-storeman/blob/devel/src/ornpm.cpp#L389

[nephros]

BTW, this bug implements #92 in a way ;)

And possibly, if my suggestion from the previous comment works, that could solve #96

[Olf0]

I was wondering if there was a way to let Storeman allow vendor changes at least for self-updates.

Yes, that would be nice, but solely for self-updates (see below).

So the PackageKit install action can perform a vendor change. (The OpenSuSE doc page on vendor changes says this as well, albeit a bit "hidden".)

Thank you, this is cool. And pkcon install seems to be equivalent to pkcon update in all other aspects (sadly, see details below), except for a second one: at least one package name must be provided.

I just tried that with the Storeman "stuck at 0.3.2": pkcon install harbour-storeman nicely offered me v0.3.4 and updated it after confirmation (in contrast to pkcon update harbour-storeman).

But I really fail to find any such statement on https://en.opensuse.org/SDB:Vendor_change_update
Am I "locally blind" (would not be the first time)?

So one solution could be to make Storeman not use the upgradePackage but rather the installPackage call for updates.

1. I was first strongly inclined to write "Yes" and about to draft a PR (as this basically is a trivial change).
2. Then I thought: "Cool, this way we can even offer update candidates for packages from the Jolla Store!"
3. But this lead me to consider that this is extremely accident prone, because updates for "system packages" would be offered from the OpenRepos repos of lachs0r, lpr / lpr_A7 / lpr_next, NielDK etc.

BTW, this bug implements #92 in a way ;)

Yeah, if only one could inject a vendor into an extant RPM package. 😏

And possibly, if my suggestion from the previous comment works, that could solve #96

Unfortunately not: I currently have four update candidates on a device, and the first of them fails (likely due to a damaged RPM file), plus trying to install this one sets packagekitd in that state where it always wants to update all packages (unless it is killed / restarted), even if it is commanded to update a specific one; "install" behaves exactly the same, the only difference is that it does not allow for omitting a package name (and that it ignores vendor changes).

---

Thus ultimately we may consider to let Storeman perform solely its own updates as "install" action, hence ignoring a vendor change. I currently tend to: This is not worth the effort, also because this is not so extremely trivial as to always perform "Install" actions instead of "Update".

But I consider the general switch from "Update" to "Install" for updating packages by the SailfishOS:Chum GUI app, because at SailfishOS:Chum there are no packages superseding "system packages" by employed rules for submitting packages, see the first paragraph of the section "Developer's guide" in the SailfishOS:Chum main documentation. But I currently fail to find where: I cease clicking through the tree now, instead I may clone and grep through the tree some day.

[nephros]

I that agreement isn't in the chum/main repo texts but was mentioned in one of the Forum threads?

[nephros]

But I really fail to find any such statement on https://en.opensuse.org/SDB:Vendor_change_update
Am I "locally blind" (would not be the first time)?

The hint is in using zypper install to allow a vendor change for a single package. So I tried pkcon and it worked there too.

[Olf0]

But I really fail to find any such statement on https://en.opensuse.org/SDB:Vendor_change_update
Am I "locally blind" (would not be the first time)?

The hint is in using zypper install to allow a vendor change for a single package. So I tried pkcon and it worked there too.

Well, the section "Single package Vendor change" states to either update to a specific version or using a specific repository to override a vendor change. But I am glad you used pkcon install to try overriding a Vendor change without specifying either, and it worked. Still this is not a behaviour of the packagekitd I would rely on to work forever, because it is unspecified behaviour and packagekitd is full of bugs so this may be unintentional; I also strongly suspect issue #96 being caused by packagekitd, which occurs regularly, but not always and apparently not deterministically, because it is independent of the front-end used (pkcon, Storeman, SFOS:Chum GUI app), plus the back-end (libzypp for resolving dependencies and librpm for the package handling proper) is well tested and maintained.

[Olf0]

I that agreement isn't in the chum/main repo texts but was mentioned in one of the Forum threads?

Sorry, I pointed to the right document, but the wrong section. Now rectified (changes in italic) the original message to:

But I consider the general switch from "Update" to "Install" for updating packages by the SailfishOS:Chum GUI app, because at SailfishOS:Chum there are no packages superseding "system packages" by employed rules for submitting packages, see the first paragraph of the section "Developer's guide" in the SailfishOS:Chum main documentation.

Still (because I did nothing in this regard since yesterday, yet):

But I currently fail to find where: I cease clicking through the tree now, instead I may clone and grep through the tree some day.

[Olf0]

From the final paragraph of this comment:

I do not want to "repair" an issue with a hammer, which I do not comprehend at all:

• I have the harbour-storeman-obs repository enabled in SSU, but Storeman and pkcon do not find an update candidate.
• On your device the harbour-storeman-obs repository is not added (or immediately removed by something) when installing Storeman, but an update candidate is found as soon as you manually add it.

Now all this has become nicely reproducible for me. ☹️

• The first point is fully understood, O.K. and (kind of) addressed by commit e3078c8: It was Vendor stickiness combined with the fact that I obviously had installed Storeman from a different source than its primary binary repository harbour-storeman-obs and forgot about it.
• After or by updating to Storeman 0.3.4 (or by starting the SFOS:Chum GUI app or switching repos in it), I can also reproduce the second bullet point (formerly known as "your issue"): The harbour-storeman-obs repository has been removed. 😭

So it is definitely worth to further investigate "your issue".

Uff, I simply checked this incorrectly. 😌
It seems to be fine, still.

---

So what remains of this thread are the derived considerations for the SailfishOS:Chum GUI app.

[Olf0]

1. For Storeman I documented the assessments, conclusions and resulted measures in the Storeman Wiki page "Storeman and vendor changes".
   

2. For the SailfishOS:Chum GUI app I filed issue 198 "Optionally allow SFOS:Chum GUI app to ignore vendor changes when updating packages" which references this issue / discussion thread.