GNOME Software and postmarketOS: a bumpy road

Nowadays, any user installing a GNOME-based (Phosh, I’m looking at you) UI in postmarketOS will probably not experience many issues with GNOME Software (GS). They will most likely play a bit around, enjoy the nice UX, search for some apps, install some of their favorites, and move on. They probably won’t give it much thought. They probably won’t know, that one to two years ago, it looked like this

And was barely functional. The only (sort of) reliable functionality were upgrades, but only when few of them were queued and GS could handle them without timing out. You don’t have to take my word for it, you can look at Distrowatch’s review. so then, what has changed in the last 1 and a half years?

Upstream work

First and foremost, “al César lo que es del César”. And in two directions:

• UI: at the time, postmarketOS’s GS was based on heavily-patched (less now than back then) and outdated (alpine’s release cycle, which postmarketOS is based on, is much faster than that of PureOS) PureOS Store from Purism, so that GS would more-or-less fit in Mobile. Now, we use the regular GS version without issues. In between, GTK4-serial-porter Georges Stavracas ported GS to GTK4 and libadwaita, Purism upstreamed many of their patches, and the main GS maintainers (Philip Withnall and Milan Crha), together with other people, implemented lots of changes envisioned by the Design Team. The result is a very nice UX experience, a beautiful app, and a fully-adaptive design.
• Backend: one of the big reasons why GS was slow (and resource intensive) in any distro was that many of the executed tasks where being done synchronously. And the upstream maintainers put the focus on it. For more than a year, they’ve very intensively worked on this, making the whole application asynchronous. They can probably explain it better than I can, so if you are interested on how and why, you can have a look at the upstream issue (with 33! related MRs as of now), and at Philip’s talk at 2022’s GUADEC. And more improvements keep coming! Like this work on icon download speed-up by Georges Stavracas.

Infrastructure

Unfortunately, to have a nice-looking Software app store, some additional bits of infrastructure are necessary. To be able to present the users with a set of apps to install, GS needs to know which apps are actually available, and extra information about each of them. The AppStream (AS) specification exists exactly for that reason. Following the spec, app developers create metainfo files, where they add information about their apps. Then, distributions are responsible for extracting all those files from their repositories, put them all together following a standarized format, and place them in users’ machines.

One and a half years ago, the infrastructure to extract the metainfo files, and make them available for download was in place thanks to Cogitri. Cogitri had written a backend for alpine’s packaging format in appstream-generator, which takes care of exactly that. However, alpine’s infrastructure[1][2] had stopped working and needed some love. I put the effort to fix it, and recently wrote alpine-appstream-downloader, a small python script that makes us compliant with the requirement that we should place those files in a pre-defined location in users’ machines. Before, that was done in GS, but was less reliable and was not able to handle changes in repository data. There was quite a discussion about those of those points in this issue in pmaports.

APK integration

Alpine Package Keeper is the packaging format used by the package manager in alpine, and in consequence postmarketOS. Like everything in alpine, it focuses on being small and simple. However, it is not widely used (yet 😉), and therefore standard integration with Software store apps was not available. When I started looking into this, Cogitri had already created a deamon to manage APK operations that need root access, and developed a plugin for GS to interact with the daemon. This was sort-of-working, but it was a custom and specific solution for a problem that had already been solved by PackageKit: how to let apps interact with package managers. Therefore, following postmarketOS principles, the real solution should have been to write an APK backend for PackageKit. Unfortunately, PackageKit had been considered dead by its maintainer for quite a while. There was some discussion in postmartketOS on how to deal with this situation, and the decision was finally to ignore PackageKit, to avoid disregarding a maintainer opinion over its own Software. That said, I still often wonder whether I should just try to write that backend, and whether that would have saved me lots of time. I would love to have a more general solution to this problem that does not depend on something mostly unmaintained and with a terrible DBus API (that is for another blog post…), but things are sometimes not what we would like them to be. That said, there has been lately some work by Matthias Klumpp and Philip Withnall to improve the situation in PackageKit. So, what has happened in the last year and a half to make GS so much more usable?

• The deamon, gnome-software-plugin-apk: together Cogitri and me cleaned up[3][4][5] the DBus interface and made it more extensible, more performant and simpler to use. I opened a discussion, and we ended up implementing the interface the closest we could to the DBus API design recommendations. Overall, I believe this was a success, and compared to the PackageKit API, is also a bless to use. I must also admit, it does a lot less things, so this might be a reason.
•  The GS plugin, apk-polkit-rs: this is probably where I sank the most of my time. The GS plugin API is unstable and a fastly moving target. This allows the GS developers to do all the amazing backend improvements they have been doing for the last years, but also means a sensible amount of maintenance downstream. Luckily, I got some help from Dylan Van Assche, that did a big effort in the port to GNOME 42. Additionally, I also implemented the new client API for the daemon, and did a lot of minor improvements to support in the plugin functionality that allows the app to show more information. The last one, for example, allowed to show all the nice apps in the “Explore Page” users see the first.
• Upstreaming work. Many of the features implemented in the plugin or in the infrastructure required some work upstream. Those were mostly related to improving minor things when GS was not strictly following the specification or had some bug. In total, I’ve sent 17 MRs in the GS repo in the last year and a half, so this also something to be considered.

Conclussion

Even though GNOME Software looks amazing in postmarketOS now, it does mean it’s been an easy path. It involved tons of work from many people, solving parts of the problem in different parts of the stack. And even though we support a great set of features, some parts of the APK integration are still missing. Like fetching packages asynchronously instead of when doing the updates, or offline updates. There are also ton of small improvements to make, and the temptation to write an APK backend for PackageKit. And although I’ve really enjoyed the ride, I am context-switching to other parts of the stack (Evince, I’m looking at you 👀) now, and moving to maintenance-mode only for the GS work. So if anybody has the desire to pick up the work done by all these amazing people and me, but don’t know how to start feel free to get in contact! You can probably find me under @pabloyoyoista in postmarketOS-devel Matrix room. I’d be delighted to help!