Right. Short checklist if a Maemo application compiles on Mer:

1. Does the Maemo application use any APIs that were deprecated in Fremantle (Mer is based on open source Fremantle APIs and any code that is using those APIs will build.). If yes, then it won't compile.

2. Does the application assume it's being built on gcc3? If so, it won't compile. We use gcc4, like Fremantle.

3. Does the Maemo application assume that it is being built within Scratchbox. Is there libtool/automake/etc symlinks into /targets/scratchbox or the likes in the source package or tricks needed to build within Scratchbox.

4. Does the Maemo application packaging assume that some packages are magically installed beyond typical build-essential dependancies. Hint: autoconf, libtool, automake is not preinstalled in build environments on a Debian or Ubuntu, if you apt-get install build-essential. If it does, add the missing dependancies to build dependancies.

5. Does it depend on certain versions of autoconf, automake, libtool, etc.

Reasons for binary Maemo application package not to work on Mer:

1. Does the package depend on special Maemo packages names for some dependancies? libsdl is interesting.

2. Does the package rely on /bin/sh being bash or busybox?

3. Does the package depend on closed source Nokia packages? (We can possibly distribute some of those with vendor repositories.)

4. Does the package binaries use deprecated symbols in Hildon etc.

5. Is it a Python application and hardwired to python2.4 or 2.5? Mer uses Python 2.6. We're working with PyMaemo to work out how to do this the best.

6. Does the package assume $USER is /home/user or assume that /home/user exists (it is actually an interesting choice of ours to have /home/whoever and I'm still wondering if it is the right one).

These are all things we hope to be able to check before packages make it into Fremantle extras (not extras-devel, -testing, etc)