Q: 4.5 will switch RPM compression. What does that mean for existing RPMs?

The announcements of 4.4 releases mentiones numerous times that the next SFOS version will switch rpm compression (from xz to zstd).

Does this change affect existing rpms using the old compression, i.e. will they still install on 4.5?

Or is ist that third party apps will have to rebuild the world to continue to be available?

1 Like

I only ever understood it to mean that 4.5 can now optionally use the new fancy compression (and will do so for jolla packages).
Do you have reason to believe otherwise?
It appears that Fedora and RedHat did the same thing… and surely the internet would have been up in arms if it was a compatibility break.


Yes, RetHat et al also do things like provide backwards compatibility (e.g.by supplying -compat packages for ABI changes), which Jolla traditionally does not. E.g. ncurses, openssl

1 Like

If this is a package-breaking change I’d like to know so I can schedule time or rebuilding all my published stuff.

1 Like

Ditto, although it seems like that’d be an option. I’ve re-iterated the question on the .72 page.

Um, where DOES one set the compression option?

It’s also interesting to know if we have to brace for another round of having to pick up working but unmaintained apps (like happened with introduction of aarch64, and SailJail).

I mean @poetaster will do 90% of that in that case as usual (I think he might be an AI to be frank), but still even digital beings have limited resources.


Answered in the other thread:

Thanks, @jovirkku!

1 Like

It’s some macros in the rpm(build) environment. And I guess probably a compile-time option for (lib)rpm as well, haven’t checked that.

This is probably going to be important to change back to xz, iff one builds on OBS with a 4.5 target, but wants to publish the result on OpenRepos (for users of older releases).

Nah, just re-discovering my love of computing after a 10+ year period of stagnation (with the exception on one crazy year building electronic musical instruments). And I hate to see perfectly functional code go to waste :slight_smile:

Next rpm issue, how to push all those heavy data parts to ~.local given the current mechanisms of rpms meeting the limits of sailjail.

Thanks for bringing compression up!


RPMs really shouldn’t install anything to user homes.

BUT, you can install into /home/.system/{usr,var,...}, which is located on the /home partition and thus has less space constraints. Only caveat it that apps must ensure they only start after /home has been mounted properly.

1 Like

I’m aware of the many reasons why (er, multi-seat systems, for one), but in practice? I’m working on stellarium (and a rebuild of machinesvs.) moving the data out of the application area, so I’ll start a new thread once stellarium is done (I fixed all the bugs).

Is there documentation about that somewhere? Should we document that somewhere?

I don’t know. The first time I came across it was when the release notes of MLS Manager mentioned it. (@abranson might have some more information?)

I think it’s main purpose is to move “confidential” but system-wide data (like e.g. wifi passwords) from plain old unencrypted /var into an encrypted location.

Hence the existence of


and similar.

1 Like

Thanks! It’s actually a reasonable solution, you are correct.

It turns out that I have to re-write some of the data loading code in Stellarium anyway. Sigh. Or I make symlinks from /home/.system/usr/share/stellarium → /usr/share/stellarium. Hmmm. I just tested this route (manually moving and symlinking) and it works fine.

If if weren’t such a lot of data, I’d already have implemented loading on first run, but it’s one of those finding a balance between what is sufficient for the first run is, well, tricky. It’s the stars, after all!

Yes that’s about right. /home/.system is a place where system-wide data is kept on the home partition, without becoming inaccessible when another user logs in.

Btw, the addition of the new compression format for rpms is a reproducible builds thing. I think the old one wasn’t always producing the same result, which meant that builds were being triggered when they shouldn’t be, and deltarpm didn’t work very well.