To improve the presentation of packages from unofficial archives, any package archive -- whether it be official, Canonical partner, PPA, or anything else -- should be able to contain a human-friendly index, describing the icons, categories, subcategories, and search keywords for its packages. There should be a way of generating this index automatically (just as Packages.gz is generated), and Soyuz should do this whenever any Launchpad archive package changes.

Release Note



The current way to provide additional meta-data for software-center is to provide the desktop files of the applications along with additional meta-data like what package they belong too.

app-install-data is something we want to get rid of:

User stories


The current data we have in the app-install-data package should be replaced by multiple indexfile that is put alongside the Packages.gz file.

For software-center are interessted in the following data:

That will prodice a "Applications.gz" indexfile that can contains multiple apps for a given package and that may contains multiple identical named apps (with generic names like "Terminal"). In order to get a unique representation the tuple (appname, pkgname) is useful.

The icons should be probably published in a seperate file:

But some research is needed in order to find a good format. We need to compare uuencoded text vs gtkiconcache or simple tarfile.

For the command-not-found-data that we want to use for this as well the data we want is:

File format

Moving the localization for the Categories/Comments into a separate file is tricky for the first version of this specification. This can be done later, we just need to be careful about backwards compatibility if we decide to have the translations inline (i.e. ensure that for lucid we still produce files with the inline translations). Alternatively we can move the translations into the langpacks. The disadvantage is that the translations will only be available after the langpack got installed (or updated).

Example for a first version with inline translations

Package: gnome-utils
Popcon: 17939
Section: main
Icon: baobab
Name: Disk Usage Analyzer
Name-de: Festplatten Überprüfer 
Comment: Check folder sizes and available disk space
Comment-de: Überprüfen des verfügbaren Platzes
Exec: baobab
Categories: GTK;GNOME;Utility;

Package: gnome-utils
Popcon: 17939
Section: main
Name: Search for Files...

Soyuz process

The current meta-data is extracted by a script that crawls over the entire ubuntu/lucid archive and looks into each deb for dekstop files, extracts them and add meta-data. There is also a table of fixup actions. Some of the common issues are that the desktop file is not in the package we are interessted in. E.g. wesnoth-data vs. wesnoth or emacs-common contains the icon for emacs22. Some of this can be fixed in the packages by the maintainer by overwriting the X-AppInstall-Package= field (or by adding a explicit X-AppInstall-Ignore=true). For some we provide manual overrides. To migrate this to soyuz, both desktop file and icon needs to be extracted after the build process, annotated with meta-data and stored somewhere.

The translations for a package are currently scattered around in launchpad. Parts of the translatiosn are in the app-install-data template (e.g. the Comment field from the desktop file). Parts are in the ddtp-ubuntu template (the long description). Both are not sorted per package and not presented for the translator alongside the package but in a seperate project. This should be fixed so that there those are displayed as separate templates in a source package (so that the translator needs to look only in one place for a full translation of a source package).


The design for libapt is described in


There are two kinds of information that we want to publish:

For the later we need a different approach because once the archive is frozen we traditionally do not update the indexfiles anymore.

Launchpad team requirements

Needs doing by beta 1 or not in Lucid at all.

The Launchpad team needs from the Ubuntu Software Center team:

Open questions

What should be done with popular package that are not available for a given architecture (e.g. skype on arm). Currently we show them and say its not available for the given hardware.

What to do with app-install-data-partner? Currently we do not enable the partner channel by default but we do ship desktop files so that its trivial to enable the partner repository from software-center. If we replace the app-install-data-partner package with a repository based approach then partner apps will not show up anymore or we need to enable the repository by default.

What about the relatively large blacklist for desktop files we have right now? There are e.g. a bunch of gpe applications that we do not show by default in software-center currently as a application because they are optimized for a different kind of device. We do blacklist other desktop files for similar reasons. Should all this be undone (with the impact to potentially clutter the applications list quite a bit)?

If we decide to keep a blacklist to avoid cluttering the applications directory we need a process and a team that is responsible for reviewing the meta-data and blacklist inappropriate applications data.

Should we add signatures to this meta-data to the Release file? The only risk I can see is a man-in-the-middle attack that injects poisoned image data that exploits a (hypothetical) flaw in the image rendering in gtk/webkit. Otherwise the data seems to be not very security sensitive. Adding signatures means the Release file gets a lot bigger for everyone (something we want to avoid with the design of multiple IndexFiles).

Disscussion notes




Two parts:

LP: • what to export?

• how many files?

* we need to hook into the build process to extract the desktop file,

Initial Implementation

Launchpad team requirements

Needs doing by beta 1, or not in Lucid at all.

The Launchpad team needs from the Ubuntu Software Center team:


FoundationsTeam/Specs/LucidSoftwareCenterRepositoryBasedIndexfiles (last edited 2009-12-02 09:13:35 by p5B09F81D)