Extending GNOME Software

Did you know...?

LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

At GUADEC 2016 in Karlsruhe, Germany, Kalev Lember spoke about the recent changes in GNOME's application-installation tool GNOME Software. The program does more than simply install packages; it provides user-visible metadata, ratings, screenshots, and other information. As new application-packaging formats like Flatpak have gained popularity, GNOME Software has adapted to work with them as well.

Lember began with a short summary of GNOME Software's history. The genesis of the project came several years ago, when Richard Hughes started developing PackageKit, which is a component that supports package installation but provides no real user interface. Hughes learned that the lack of a user-level installation tool was effectively keeping his wife from running GNOME, so he set out to build a solution.

Initially, the GNOME front end for PackageKit ("GNOME PackageKit") merely exposed the internal structures and APIs of PackageKit, which was not user-friendly. The error messages from PackageKit, for example, tended to be obtuse, reporting low-level problems like two packages that attempt to provide the same file. In 2012, though, the application was redesigned from the ground up by Jakub Steiner, Jon McCann, and Allan Day, resulting in GNOME Software. The architecture, Lember said, is not nearly as clean as GNOME PackageKit's, but it provides the interface that users need. Maintenance is harder, he said, "but it's a small price to pay if we can have happy users."

There are tradeoffs made in the new design. First, GNOME Software does not attempt to provide access to every package on the system, focusing instead only on "applications" (loosely defined as interactive user programs, almost all of the GUI variety). Second, because applications are "first-class citizens," a useful, human-readable description and a screenshot are required for every application.

Both of those metadata items are provided by AppData files. Initially, AppData was not used much, Lember said, but after it was released in Fedora, there was a huge uptick in application projects that provide AppData files. The specification has also subsequently been adopted by other projects, including Ubuntu's snap package format and KDE's Muon package manager.

Rate this

Recently, Ubuntu decided to start using GNOME Software as its application installer, replacing the previous Ubuntu Software Center. But Ubuntu wanted to add support for a user reviews and a ratings system, features long provided in Ubuntu Software Center but that had not been implemented in GNOME Software. Ubuntu developers added front-end code for ratings and reviews, and Hughes wrote back-end support, starting with a generic rating-and-review server called the Open Desktop Ratings Service (ODRS).

The rating-and-review system supports a configurable server source so that individual distributions (or, perhaps, enterprise deployments) can link GNOME Software to their own ODRS system. Ubuntu, for example, links the application to its pre-existing rating-and-review database. Lember said that ODRS is rather open: anyone can post a review if they know the proper API calls, with no need to create an account. "I, too, was very skeptical about this," Lember said, when Hughes explained that design to him. "But he is stubborn, in a good way, and he went ahead," he added.

Despite the fact that authenticated user accounts are not required to post reviews, there are some administrative controls. Information about each user's machine is hashed on the server to act as an internal ID, and the ODRS administrators can ban reviewers if necessary. In the GNOME Software interface, users see an "is this review useful?" question on reviews; if too many users flag a particular review as problematic, the expectation is that administrators will take action. So far, he said, the system has worked remarkably well: there have been only a few badly behaved users, and all were caught within a matter of hours.

In response to an audience question, Lember added that it is technically possible for programs other than GNOME Software to fetch review information directly from an ODRS server, although that is not the intent. The server provides a JSON API, so client code will have to deal with that output format and, at present, there is no "bulk download" facility.

APIs, upgrades, and future work

In the current development cycle, GNOME Software has added a public plugin API. The architecture was already plugin-based internally, Lember said, to support backends for different package engines (namely RPMs and Debian packages). Although GNOME Software was largely a Fedora effort at first, it now gets contributions from Ubuntu, Debian, SUSE, and Red Hat Enterprise Linux, which Lember noted was a "great example of cross-distribution cooperation."

The API has allowed developers to add support for Ubuntu's repositories, Flatpak, OSTree, and Limba, and making it public will enable developers to write out-of-tree plugins. That could be useful for enterprises, which can enable support for their own private systems without the burden of maintaining a fork of GNOME Software.

Another important new feature is the ability for GNOME Software to handle distribution release upgrades. Fedora supports this upgrade method as of the Fedora 24 release.

Looking to the future, Lember noted that some work will be necessary to support the OSTree model, in which the base system is provided as an immutable OS image and individual applications are packaged in self-contained bundles (such as Flatpaks). GNOME Software's view of the system becomes challenging in this type of environment, particularly how to present state to the user when a package is both part of the immutable OSTree image and is available as a Flatpak bundle. The team is already looking at how to distinguish between Flatpak-like bundles and standard distribution packages (such as displaying a "shield" icon on the bundle to indicate that it is sandboxed and, thus, should be safer).

Other challenges moving forward include the possibility of automatically building sandboxed bundles directly from distribution packages (something that the Flatpak project has already been working on). There may also be a need to distinguish somehow between free-software applications and proprietary applications; since sandboxed bundles like Flatpaks can be delivered by third-parties, it will be important to provide users with licensing information if at all possible.

In the question-and-answer period at the end of the session, Lember said that there are currently no plans to add back-end support for language-specific software repositories like the Python Package Index, since there are few graphical applications distributed through such systems. But there is nothing to prevent their inclusion in some later GNOME Software release.

An audience member also asked whether GNOME Software could be used to help strengthen the direct relationship between project developers and end users, which is a topic GNOME has grappled with in recent years. If GNOME Software can link users to the upstream developer, rather than to the distribution's package repository, then feedback, bug reports, and even payments could be simpler. Lember replied that GNOME Software can easily add links to project homepages and so on, but that such information should be made part of the AppData specification. He also noted that improving connections between developers and end users is already a goal of the application-sandboxing projects.

[The author would like to thank the GNOME Foundation for travel assistance to attend GUADEC 2016.]