Monday, June 6, 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 :)

No comments:

Post a Comment