What's Jolla's view on how to deal with the RPM format change?

General
1

Jolla decided to change the RPM format (see discussion over here Q: 4.5 will switch RPM compression. What does that mean for existing RPMs?)

A direct consequence is that RPMs build in a SFOS 4.5 toolkit can no longer be installed on older SFOS versions.

Jolla only writes a few lines in the changelog and that’s it, leaving all further consequences up to the developers.

But what had Jolla in mind when considering this change?

  • We just abruptly break compatibility with older SFOS versions
  • We will release an new rpm for other SFOS versions that will support the new compression
  • We want you to add settings to spec files so only the old compression is used
  • We want you to avoid the new toolkit as much as possilbe
  • Something else, namely …

Why not write a ‘blog/Sailfish Community News’ about this, explaining what was done and why and how to deal with it (just like the sailjail change)? Flypig did a great job filling the gap between Jolla and the users/developers, but now that he has left the company I am afraid this gap will return.

4 Likes
2

Wow, that’s a bit silly. And i’m not exactly big on supporting old versions…
I had just assumed it was an opt-in switch that Jolla would apply to the system packages to save bandwidth and/or speed up upgrades.

Edit: Another related finding is that the harbour webpage does not seem to identify this as breaking compatibility with older releases.
S’Play is currently released with zstd, and has no detected limitations (of course in part due to being noarch).

3

Putting this in the RPM spec switches back to the old xz format:

%define _source_payload w6.xzdio
%define _binary_payload w6.xzdio

TBD if that is the correct compression level.

Compression type checked with:
rpm -q --queryformat '%{PAYLOADCOMPRESSOR}\n' -p somefile.rpm

Edit: sorry for obvious info; that was already all over the other thread. I had just forgotten.

3 Likes
4

Alternatives are already discussed in the discussion link I provided. I just would like to hear how Jolla think we should deal with this in their view.

5

Maybe better ask Jolla.

6

No, it is the wrong compression level and method for sources!

The source compression shall either be left as it is or be set to gzip -6 … -9 (6 is gzip’s default). For the binaries it is fine to use xz -2 … -6; for RPMs which are only installable on SailfishOS ≥ 3.2.1 one may add the option -T.

Yes, this all has been documented before in depth.

2 Likes
7

Does the compression level really matter as long as the algorithm is correct? I can’t really imagine why.

8

Looked at this way, nothing matters as long as the compression method is supported by all releases targeted.

But practically, e.g. xz -9 is incredibly slow on decompression and eats at least 70 MB RAM only for that, so maybe your device OOMs, you have to close an app or two and retry. Plus some people will state “does not work”, because they run out of patience and kill the “hanging” Storeman / SailfishOS:Chum GUI app, before the installation of the rpm file finishes.

4 Likes
9

for SFOS 3.4 to 4.2 there now is a libzstd enabled version of rpm 4.14 suitable e.g. for a Jolla1:
https://openrepos.net/content/lpr/rpm-legacy-sfos-34-42

4 Likes