AppStream Clarifications

appstream-logoWhile reading stuff posted by others about AppStream, and because of the discussion happening about AppData on kde-core-devel right now, I feel the need to clarify a few things. Especially because some are implementing AppStream in a way which is not really ideal right now. This is to some extend my fault, because I should have communicated this in a much more visible way.

To those people who don’t know it already: AppStream is a Freedesktop project aiming at providing basic building blocks to create distro- and desktop-agnostic software centers.

So, let’s answer some questions about AppStream!

Is AppStream GNOME or $distro specific?

No, not at all! It was originally created by people from at least 4 different distributions, and I took great care of it not becoming specific to any desktop or distribution. GNOME just happened to go ahead and implement the specs, which was absolutely necessary, since there was less progress in implementing AppStream for a long time.

How does AppStream actually work?

AppStream is a bunch of things, so I will only focus on what we have specified right now and what is working.

Basically, the distributor compiles a list of applications available in the repositories, and makes it available in some defined directories on the system. AppStream defines an XML specification for that, but since some peple don’t want to use it or can’t use it, there are also others ways to publish AppStream application data. For example, Debian will likely use YAML for that.

This data is taked by the AppStream software (running as a PackageKit plugin) and transformed into a Xapian database. This database is then in turn used by software-centers, in combination with PackageKit, to present applications.

This is the reason why it is bad to use the XML data directly – it might not be available on every distribution. The Xapian database is what matters. The database can be accessed using libappstream, a GLib based library (so far, there was no need for a Qt version).

Why is GNOME using the XML data directly then?

The libappsream stuff was under heavy construction, and GNOME wanted to be fast and ship the stuff with Fedora in their next release. They’ll likely switch to the Xapian db soon, or offer it as backend.

Is AppStream already used in KDE?

Yes, Apper can utilize it, see one of my previous blogposts.

What is AppData?

AppData is an initiative started by Richard Hughes in order to enhance the quality of applications descriptions shipped with AppStream. It defines a small file $appname.appdata.xml, which describes the application, sets screenshots etc. These files can be parsed at the distribution’s side in order to enhance the app metadata. They can also be translated upstream.

AppData might be merged into the XDG AppStream pages later, but that is to be discussed.

Are application authors forced to ship AppData files?

No, nobody is forced ;-) However, the GNOME Software application-center prefers applications shipping more metadata, and “punishes” the others, so shipping an AppData file makes sense for higher lising in GS. This is a policy decision by GNOME, KDE can make it’s own ones here.

Shipping AppData files makes sense, in general, because it enhances the metadata distributed with your application. It is also the file-format used by Listaller (well, a superset of it) in order to generate cross-distro app-packages, so you might want to consider adding one.

Are there any rules for the AppData files?

Yes, you can find them on the AppData specification page. However, these are more recommendations than “forced”, and it is currently aimed at GNOME apps. I later want to generalize that and create an own page with recommendations for KDE (martin had some good ideas already).

Where do software-centers get the screenshots from?

The screenshots are defined in AppData files, and the cached by the distributor. If there are no “official” screenshots, user-provided screenshots will be taken, using a screenshots-service with screenshots.d.n-like API.

Where do I find the specs?

The official AppStream spec, the thing which distributors should implement, can be found on Freedesktop.

The AppData spec can be found here. It also includes some nice hints on how to handle screenshots etc. and includes it’s own FAQ.

Where do I find libappstream?

The source code can be found on Gitorious, releases are available on fd.o software. Contributions to the code are welcome!

I want to change X in the spec, because of argument Y which brings improvement Z

Great! Please get in contact with me or Richard. The only feature we would not consider for the official standard is desktop/distro-specific stuff (which should be obvious ;-) ).

I will extend this FAQ, if I feel the need for it, so this article might change a bit.

5 Comments

  • Martin Gräßlin commented on 4. November 2013 Reply

    After reading the thread on kcd I’m really glad that this whole topic is not relevant to me :-)

    • Matthias commented on 4. November 2013 Reply

      Not really :D You only let KWin provide window borders for screenshots ^^
      In this case, I hope we don’t get one of the KDE/GNOME fights, since this stuff was really developed by multiple people from different groups :-) Let’s see ;-)

  • Olivier Berger commented on 4. November 2013 Reply

    May I suggest that you forward this to : distributions@lists.freedesktop.org too (unless there’s a more specific appstream list) ?

  • Anon commented on 4. November 2013 Reply

    Soon GNOME will be doing more than punishing programs that don’t have AppData:
    “in GNOME 3.14 we’re not going to be showing them [applications that don’t ship AppData] at all”
    from http://blogs.gnome.org/hughsie/2013/11/01/upstream-adoption-of-appdata-so-far/ .

    However as you said KDE can have its own policy – it’s not dictated by AppStream.

  • Yuri Chornoivan commented on 4. November 2013 Reply

    Most of the independent (non-desktop-inbuilt) applications adopt this spec in a very simple (I’d say barbaric) way. They just put *.appdata.xml in the corresponding folders.

    Blender, Audacity, Scilab, PSPP… That’s only the projects that I’m aware of.

    And that’s not because they are bad. This system was not thought to be translatable from the beginning. And please do not say that everybody should adopt intltool or itstool. These are mostly Gnome-centric tools not suitable for every project build system. To be honest, they only work for autotools. Richard knows this and sends such untranslatable files to the projects like Blender.

    I’m not happy with the current situation with package descriptions translations but, forgive me, this is just another untranslatable crap crawling into the distros for the years to come. At least in the current form.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>