How to provide SailfishOS:Chum metadata, if the Vendor: has to be set to someting else than chum in order to keep the upgrade path intact, e.g., at OpenRepos.

[Olf0]

How to provide SailfishOS:Chum metadata, if the Vendor: has to be set to someting else than chum in order to keep the upgrade path intact, e.g., at OpenRepos.

[rinigus]

Do you have any package as an example of this issue?

[Olf0]

sfos-upgrade

[rinigus]

You have set yourself as a vendor which made corresponding %if in SPEC to be false. See the result

Information for package sfos-upgrade:
-------------------------------------
Repository     : sailfishos-chum-testing
Name           : sfos-upgrade
Version        : 3.9.15-1.7.1.jolla
Arch           : noarch
Vendor         : olf
Installed Size : 45.0 KiB
Installed      : No
Status         : not installed
Source package : sfos-upgrade-3.9.15-1.7.1.jolla.src
Summary        : Scripts for fail-safe upgrading of SailfishOS at the command line with logging
Description    : 
    Scripts for fail-safe and semi-automated upgrading of SailfishOS at the command
    line with logging

    Usage: sfos-upgrade [<version>|--verify|--help]

    With a version number provided as parameter it sets SSU to this version and in
    release mode before upgrading.  This is the regular use case.

    Without a version number it retrieves the one set for SSU to perform slightly
    relaxed checks, but does not alter SSU's settings for upgrading.

[Olf0]

Thank you! 🤦 Though now I see that I have problem: Changing the vendor breaks the upgrade path at OpenRepos.

So I assume that the only option is to enable the SailfishOS:Chum metadata unconditionally, which does not look very nice. So what, who looks at the RPM metadata on SailfishOS? Storeman does not display it, it takes the description from OpenRepos.

Or is there any other RPM variable I can check, which indicates that the package is being built at the SFOS-OBS? That would provide an easy way out.

[rinigus]

Not that I am aware of. Addition of vendor was made to allow users to choose the source of installed package. As a side-effect, it was used by most for %if statement. On my packages, I don't use %if and consider tag info as useful in the description (if someone checks it with zypper).

[Olf0]

I have found two ways:

• OBS documentation: OBS-specific RPM macros: OBS automatically sets %_project and %_repository
• OBS documentation: Project specific macros, which can be set in the Project tab

I will experiment, what I can get working a my OBS-repo@SFOS-OBS.
Aim: To find something, which carries the same value for both, SailfishOS:Chum and SailfishOS:Chum:Testing.

[rinigus]

Note that this "something" can probably be added to https://build.merproject.org/project/prjconf/sailfishos:chum . Just have to know what :)

[Olf0]

Yes, exactly, but it would have to be set in both, https://build.merproject.org/project/prjconf/sailfishos:chum and https://build.merproject.org/project/prjconf/sailfishos:chum:testing

I am currently trying

Macros:
  # Add %%_chum boolean macro and set it to 1.
  %_chum 1
:Macros

It can be tested for existence by %if %{defined <macro>} and the awkward, hardly readable arithmetic evaluation utilising the ternary operator %if 0%{?<macro>:1} != 0, as any other macro, which resolves to a string, integer number or boolean. For the boolean variant, also %if 0%{?<macro>}, %if %{?<macro>} (without setting a default), %if %{<macro>} (without explicit evaluation) or simply %if %<macro> should work; but for the latter three variants the macro must exist, otherwise it resolves to nothing.
Edit: This page at backreference.org explains RPM conditionals well and almost exhaustive, while the original RPM documentation is complete, but too terse.

OTOH, a "simple" check for the macros set by OBS is also sufficient:

%if "%{_project}" = "sailfishos:chum" || "%{_project}" = "sailfishos:chum:testing"
<SailfishOS:Chum metadata>
%endif

[Olf0]

Oh, I just realise that I do not really comprehend this statement:

Addition of vendor was made to allow users to choose the source of installed package.

How would one use that? If one has a repo enabled, one has access to all packages in it and neither pkcon or the SailfishOS:Chum GUI app can filter for the vendor. Luckily!
(zypper is not installed by default and rpm only works on local packages.)

[Olf0]

@rinigus, after a lot of checks and balances (e.g., how many underscores to use: Reading rpm --showrc in its entirety makes the conventions obvious) I settled on my initial suggestion:

Please set in both, https://build.merproject.org/project/prjconf/sailfishos:chum and https://build.merproject.org/project/prjconf/sailfishos:chum:testing

Macros:
  # Define %%_chum boolean macro and initialise it with "1":
  %_chum 1
:Macros

Thank you!

The simplest safe form of usage is (resolves to 0, if the macro does not exist, otherwise to its value with a 0 prepended):

%if 0%{?_chum}
<SailfishOS:Chum metadata>
%endif

Tell me here, when its done, and I will test.

[rinigus]

I have just added them

[rinigus]

How would one use that? If one has a repo enabled, one has access to all packages in it and neither pkcon or the SailfishOS:Chum GUI app can filter for the vendor. Luckily!

Vendor is used automatically by pkcon and zypper. For example, if you distribute your app using Chum, Jolla Store, and OpenRepos. In Jolla Store you should keep a package without any vendor specified. In Chum, we suggest to have 'chum' as vendor - configured by default (see https://build.merproject.org/project/prjconf/sailfishos:chum:testing). In OpenRepos, you could set it to something else. Then, when user installs from one of the stores, it will stay with the same store.

For example, if you have Pure Maps installed from Jolla Store. Then, when update is released in Chum but is going through review at Jolla, users preferring Jolla Store version would not get update from Chum. That way user has a control over a channel that is used to update each app.

[Olf0]

Vendor is used automatically by pkcon and zypper.

Sure, because of libzypp's "vendor stickiness".

[…] That way user has a control over a channel that is used to update each app.

Well, I would say that it is the principally the repo maintainer who "controls" the vendor setting: fully in case of the Jolla Store, and by setting a default in case of the SailfishOS:Chum repos. At least the packager can override this for the SailfishOS:Chum repos and it is fully up to him at OpenRepos; IMO that is "control" of the vendor setting for both. Furthermore it is unset by default at OpenRepos and I assume one can unset it by Vendor: for the SailfishOS:Chum repos. Edit: No, unsetting the vendor at SailfishOS-OBS seems to be impossible, neither in the "Project Config" of a repository by %undefine vendor or macros: vendor :macros nor in the spec file by %undefine vendor or Vendor:; setting the vendor to "" or '' sets it to exactly that!

But the users do not understand this at all or have any "control" over it, even though I believe that most of them are happy that this is used as a mechanism for "repository separation" (without being aware of the technical mechanism), because Jolla / SailfishOS does not support the classic repository separation / stickiness mechanisms.

But ultimately I now see that this is just a matter of wording and / or perspective. I just wanted to be sure that I did not miss a technical aspect. Thus, thank you very much for the clarification what you meant.

[Olf0]

Conclusion:
Both, %if 0%{?_chum} (tested by looking at sfos-upgrade-3.9.17 in the SailfishOS:Chum GUI app v0.5.5) and %if "%{_project}" = "sailfishos:chum" || "%{_project}" = "sailfishos:chum:testing" (tested by looking at sfos-upgrade-3.9.16) are working fine. I will introduce the former into my write-up in issue #100.

Thank you!