Montag, 6. Juni 2011

On app stores, compliance, packaging and tooling

I've been ranting about packaging requirements for app stores and the long roundtrip time and back-and-forth messaging that needs to take place until a package really gets published into an app store before. My experience here is with Nokia's Ovi Store and Intel's AppUp Center, and I'm obviously more interested in the Maemo and MeeGo-related parts (Ovi supports Symbian too, and AppUp supports Windows). First up, here are the documents that formalize the requirements:
Both documents basically describe how packaging should take place, and this diverts somewhat from what upstream distros' packaging guidelines say (i.e. Debian in case of Maemo and Fedora in case of MeeGo). You have to install things in /opt, your binaries have to have a namespace to avoid clashes, there are different requirements for .desktop files and don't get me started on icon installation locations and sizes. Most of these things are already defined by, but stores tend to have their own, incompatible rules. This means that as an application developer, you basically have to "rewrite" your packaging for every store/target/device, which is tedious and error prone.

Also, in case of Qt applications using qmake as the build utility, can't we have some magic qmake commands/macros that would do the Right Thing in terms of packaging for a given store? All that would be required is a list of metadata (name, "namespace"/domain name, description, category, ...) and an application icon, and the rest can be figured out by the build system (I'm thinking of the MeeGo Factory video here - put a qmake-based Qt source tarball in at the one end, and get an AppUp-compliant RPM, Ovi-compliant DEB, etc.. out at the other end - without having to care about distro-, store- or even device-specific packaging differences).

Apart from the fact that one has to do much special-casing, the other problem is that the rules are not always clear, and can be interpreted in multiple ways - the only way to find out if you picked the right interpretation is to wait for a few days (AppUp in my experience has been faster than Ovi Store with that) until you get feedback from the QA teams.

I would really like to have an automated "package checking" tool (provided by an app store vendor, i.e. Nokia or Intel) that I can run locally before I upload my packages, so that packaging bugs can be removed very early on (i.e. assuming 3 iterations to get the package right, and an estimated 3 business days of QA response time, the "upload and wait for feedback" approach would be approximately two weeks, whereas the "check locally using automated validation tool" approach would take about 3 days, because I can do the three iterations locally in about an hour and then wait 3 days for the QA team to check the contents, etc..).

So, my wishlist for a good app store - developer relationship:
  1. Provide automated tooling to check for packaging errors/compliance
  2. Make sure to align as much as possible with and other app stores
  3. Provide example packaging, add positive and negative naming/config examples to the docs
  4. Provide an easy way to check for and fix package dependencies
  5. Allow developers to submit new versions from the command line / via scripts (requiring the developer to go to a website and using an upload tool is not developer friendy :/)
  6. Allow developers to upload new versions while an old version is still in QA (AppUp, I'm looking at you)
I'm really starting to wonder if it wouldn't be better to integrate the app stores more with tools like OBS and other developer-friendly utilities, and looking forward to better developer experiences in Ovi and AppUp in the future. In the mean time, I'm really happy with the Community OBS :)


Daniel hat gesagt…

Thanks for the blog post on what app stores could do better. Even though I wrote the article, "MeeGo Packaging and Compliance Guidelines" based on the MeeGo Compliance Document, I found myself in very much in agreement with you. I wanted to respond to you blog post as quickly as possible. However, I spent the night at the emergency room with my son last night and I'm not lucid enough to give a good reply at the moment. So I definitely have some comments, pointers to projects for you, some clarifications and I want to underscore the things that you wrote that I agree with myself.

sergiusens hat gesagt…

Most of the stuff you mention are more related to MeeGo compliance, things such as icons size and namespaces are stated in the MeeGo compliance document, AppUp I guess just uses those same practices and recommendations for when you submit applications.

There is however a tool that could allow you to verify that you are indeed compliant. That tool lives on and is called the app-compliance-tool

PS: I work for AppUp on MeeGo, you can take my comment with a grain of salt or verify what I said :-)

Daniel hat gesagt…

I wanted to let you know that you're post has been passed around internally at Intel, and so people have heard you. It would be great if more people would blog about their experiences. The more feedback the better.

As far as application validation in the Intel AppUp Center, we get all of our rules for application compliance from our upstream, the MeeGo Compliance document ( This document is from the MeeGo Compliance Technical Steering Group. You can find out more about about MeeGo's open governance at
I do agree with you that this document should be more aligned with the methods of other Linux distributions, especially in the areas of where installed files should go and how 3rd party dependencies are handled. The applications validation team and the technical marketing engineers(people that help developers on a technical level to get their apps in the store) are on the front lines of customer and developer interaction, and when guidelines that we must follow do not align with standard practices in the Linux world, it creates quite a lot of extra work for us.

You bring up some great points in your wishlist. Let me response to a few of them.

1. Provide automated tooling to check for packaging errors/compliance.
There is a tool that creates a compliance report of an RPM. You can read about it at and get the source code at Hopefully, in the not too distant future this tool will be included with the MeeGo SDK.

2. Make sure to align as much as possible with and other app stores.
Agreed. You can contact the MeeGo Compliance Technical Steering Committee and join the conversation MeeGo has an open governance module. Or continue to blog

3.Provide example packaging, add positive and negative naming/config examples to the docs.
More docs are coming soon both on and

4. Provide an easy way to check for and fix package dependencies
Same answer as question 1.

The last two point are for the web development team. I've forwarded these on to them.