How to enable Software Center support on your distribution

Hi!

My SoC project is nearly finished now, which unfortunately doesn’t mean that we will have a completely usable Software Center on all distributions – but the most difficult steps are done, all specification issues solved and I talked to many people from other distributions about the AppStream project and we made lots of progress. I’ll publish details in my GSoC final report 😉 This post is meant as a guide which steps are necessary to make distribution X support the AppStream project and – using AppStream – an application-centric software management solution and Software-Center-like applications.

1. Write/update your PackageKit backend

We rely on PackageKit for package management, so to support your distribution, we need a backend for your package manager.

Make sure that your backend supports parallelization! This feature is used heavily in application-management frontends like the Ubuntu Software Center and will generally make your backend much faster.

2. Package AppStream components and ship them

First of all you will need of course to ship PackageKit. Also we need AppStream-Core (with UAI) to be installed. (I’ll make a first alpha release of this after my GSoC project is complete and I discussed some things regarding this piece of software with my mentor(s)) If you want, you can also ship the cross-distro version of Software Center – you’ll need to package it’s dependencies too, some extra Python components aren’t present in all distributions.

3. Generate AppStream data

This is the most important step. AppStream data can be provided in the Ubuntu AppInstall format or Debian DEP-11, but we suggest you use the AppStream XML spec which is supported on every distro. You need a script which generates this data from packages and application’s desktop files which fits your distribution’s needs. (This script needs to run on the distribution’s servers) OpenSUSE and Fedora already have these generator tools. You also need to make this script extract icons from packages, so the software-center-implementations can display icons of not-installed packages.

The data should probably be regenerated automatically every week on distro branches which are rolling-release or in development. For stable distros where package names don’t change and no applications are added or removed, generating the data at release-time should be enough.

4. Ship AppStream data

You can ship AppStream data any way you want. You can package it as a regular package (done in Ubuntu) or advise the package manager to download it as part of the repository metadata (planned on-request for Debian). You just need to make sure the XML files end up in /usr/share/app-info/xmls and the icons are placed in /usr/share/app-info/icons . It makes sense to encode the repository name in the XML file name to avoid filename-conflicts if another (3rd-party?) repository wants to install application data with the same name.

If you use the package-way to make the data available, make sure to depend on the “update-appstream-index” tool and execute “appstream-index –refresh –nowait” in the package postinstall script, so the AppStream index is rebuilt. If you use another way to deliver the data, make sure to trigger the cache rebuild there too.

5. (Optional) Adjust the Software Center application

If you use the cross-distro non-CLA-fork of the Ubuntu Software Center, you maybe need to add a profile for your distribution to it. At time we support Ubuntu, Debian, Fedora and OpenSUSE already. You also might want to do other adjustments to fit your distribution’s needs.

If you don’t use the USC, you can skip this step and just use another implementation. (A “Light Software Center” by the Xubuntu/Lubuntu team is already in progress, as well as something done by the Elementary project. I’ll write a blog post about these projects as soon as they become more mature)

6. Test it!

There might be some quirks in your data which need to be removed, e.g. applications listed which don’t belong there, wrong descriptions, apps listed twice, system services (KDE!) listed, very slow PackageKit backend etc. So, this feature just needs testing now. Otherwise everything should be set up and ready now 🙂

Please note: I’ll update this blogpost with new information if I find something I forgot to mention above. If I do changes, I’ll add a short note about the changes here.