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:

• Maemo 5 Ovi Store Entry Requirements
• MeeGo Packaging and Compliance Guidelines

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 freedesktop.org, 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 freedesktop.org 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 meego.com Community OBS :)

Ovi Store Requirements vs. Extras Testing QA

If you want to publish your applications on Ovi Store for Maemo 5, you have to fulfill certain criteria for the package to be accepted. The technical ones are listed in the document Maemo™ 5 Applications: Ovi Store Entry Requirements. Here are some problematic entries that were not clear to me in the beginning (coming from Extras QA and a Debian-based background):

• The file must be named myapplication_1_0_1.deb (for an application that is called "myapplication"). Interesting factoid: The version number must include three digits (one can interpret that as "no less and no more"). That's different from the Debian standard naming of myapplication_X_armel.deb (where "X" can be any format version number, and "armel" specifies the target architecture). So if you have packaged your application, make sure to rename the file after upload.
• The relation of the file size of /opt compared to the files in /usr must be greater than 1:80. Here's an example from That Rabbit Game: /usr contains two files: The icon (7kB) and the .desktop file (128b) and /opt contains one file: The binary (658kB). However, the difference between these two is not a factor of over 80 when compared with "du -sh" (depending on the filesystem settings).

With that said the structure of the testing criteria in that document is very clear and (apart from some problems with the detailed specs), everything is understandable, well thought-out and can be tested by following the instructions in the document. Some of these could be use to "formalize" the Extras-Testing QA checklist here on Maemo.org or at least provide an easy-to-follow guide for carrying out the basic tests.