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:
- Provide automated tooling to check for packaging errors/compliance
- Make sure to align as much as possible with freedesktop.org and other app stores
- Provide example packaging, add positive and negative naming/config examples to the docs
- Provide an easy way to check for and fix package dependencies
- 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 :/)
- Allow developers to upload new versions while an old version is still in QA (AppUp, I'm looking at you)
3 Kommentare:
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.
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 meego.com and is called the app-compliance-tool http://wiki.meego.com/Quality/ComplianceTools
PS: I work for AppUp on MeeGo, you can take my comment with a grain of salt or verify what I said :-)
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 (http://wiki.meego.com/File:MeeGo-Compliance-Spec-1.1.0.0.pdf). This document is from the MeeGo Compliance Technical Steering Group. You can find out more about about MeeGo's open governance at https://meego.com/about/governance.
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 http://wiki.meego.com/Quality/ComplianceTools and get the source code at http://meego.gitorious.org/meego-developer-tools/meego-compliance-tools. 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 freedesktop.org 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 http://developer.meego.com/ and http://appdeveloper.intel.com/.
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.
Cheers
Kommentar veröffentlichen