Storeman & vendor changes

A vendor change of a package (RPM file) by setting the Vendor: tag in its spec file differently blocks its update path on SailfishOS. I.e., a newer version of a package with a different vendor set (or unset when the older version had it set) will not be recognised as an update candidate by all tools which directly or indirectly utilise libzypp (e.g., pkcon / packagekitd on RPM-based Linux distributions, zypper, Storeman, SailfishOS:Chum GUI app, Jolla Store client). For some background information, see OpenSUSE's documentation on "vendor stickiness".

Vendor changes of Storeman packages

Storeman has had a single deliberate vendor change, plus a few accidental diversions:

1. Historically Storeman had no vendor tag set for all Storeman releases which were primarily distributed via OpenRepos; i.e., Storeman < 0.2.9.
2. When Storeman started being built and distributed via SailfishOS-OBS, it automatically set the vendor tag to meego, because that is how Jolla configured the SailfishOS-OBS.
   Side note: This can be overridden by a OBS project configuration, as SailfishOS:Chum does by setting the vendor to chum, and both settings can be overridden by a vendor tag in a spec file.
   This vendor tag change from unset to meego was deliberate, because when updating an installed Storeman < 0.2.9 to any higher version, Storeman must be reinstalled, i.e., the old version must be removed before the new one can be installed. This can be performed via the Storeman Installer or manually. Hence it was crucial that Storeman releases ≥ 0.2.9 were not presented as a update candidate for prior releases.
3. Thus the Storeman Installer must not have the vendor tag set in order to be recognised as an update candidate for an installed Storeman release < 0.2.9. Unfortunately it seems to be impossible to unset the vendor tag, hence any Storeman Installer built at the SailfishOS-OBS is unsuitable; hence Storeman Installer was removed from SailfishOS:Chum and the principal Storeman repository at SailfishOS-OBS on 7. May 2023 (after being available there for more than a year).
   Consequently only Storeman Installer releases built by the GitHub CI are suitable to be deployed via OpenRepos!
4. Unfortunately Storeman releases 0.3.0 to 0.3.2 (inclusive) were also distributed via SailfishOS:Chum with their vendor tag set to chum and all Storeman builds by GitHub's CI runs prior to v0.3.5 (GH-CI was first implemented for v0.2.12) have the vendor tag unset. The latter are still available on Storeman's releases page at GitHub and will not be removed. Starting with Storeman 0.3.5 the vendor tag is set to meego by its spec file, so since then all builds will be mutually offered as update candidates, regardless where and how they were built.

Vendor changes of packages managed by Storeman

Storeman must obey "vendor stickiness", even though a way was discovered how to override it. This is because all packages built by Jolla for SailfishOS ("system packages") have their vendor set to meego and a few repositories at OpenRepos offer packages with their vendor tag usually unset which supersede some "system packages"; these packages would be offered as update candidates, if a repository at OpenRepos which offers such "system package"-superseding packages is or becomes enabled. As installing such packages is a recipe for disaster when performing the next SailfishOS upgrade without removing them beforehand, Storeman shall not promote installing such packages by offering them as update candidates.

Vendor changes of packages managed by the SailfishOS:Chum GUI app

^{Note that the SailfishOS:Chum repository differs in this regard, because "system package"-superseding packages are not allowed there, plus package submissions are manually scrutinised. But due to an old, lasting bug in packagekitd it is not suitable to optionally allow SailfishOS:Chum GUI app to ignore vendor changes when updating packages by sending packagekitd a D-Bus install message for each update candidate.}