The problem
Executive summary: App Manager doesn't provide a way to manage add-ons and associate their packages with apps. Instead, they appear in the listing with full apps. This leads to bloated, long listings of apps to install that contain non-apps.
I've packaged up a few different games for maemo now and almost invariably run into the same problem: there's a huge gap between a full-fledged /user app that shows up in HAM's (Hildon App Manager) listing and, well, anything else. This is a problem because there are many things that need to be installed by GUI that are not full applications. It seems that using debian packages and related utilities is the obvious way to deliver these parts; the interface is where the problem arises.
HAM: Museum or Library?
When i open up HAM, i want to visit the Museum of Maemoware: to be able to browse through a list of complete, independent apps for my device. I suspect that is what most users also expect. This means that making every add-on and optional part of apps visible in HAM is going to be overwhelming and unwieldy to the end user, and render the UI useless. Even the number of packages in -devel right now is approaching overload given the current granularity of package cataloging.
An alternative way of classifying HAM is that it is actually intended to be a library, not a museum: simply an interface to the repositories. Whether that's what "maemo" had in mind for it, i don't know, but i don't think that's what most people expect from it, even if it needs to serve that role, too. Right now there's no "in between": either a package is in HAM (meaning it's in a user/* category), or it's not.
Examples
Let me give a couple examples. UQM is a classic game that has (in debian) a binary package and various data packages. One smallish data package is required for the game to function. The other two larger ones are completely optional, but add substantially to the user experience.
In this case, i made the required data package a dependency of the game package, and put the other two packages together in a massive 130 MB package that shows up under Games in HAM along with the binary package. The user can add or remove this content at any time, as it should be, but it's also hanging out there for all to see, even those who don't have uqm installed. Furthermore, i reduced the user's choice by combining the two packages (which i did to reduce the clutter in HAM). This has the additional pathological problem of testing (10 tests for a package with nothing but a single large data archive in it?), because all packages that show up in HAM (rather than just being installed as dependencies) have to go through Extras-testing.
Case 2: Doom. Prboom is one of several doom engines that could be ported to fremantle. The variants actually have fairly different capabilities (e.g. strong multiplayer capabilities, faithfulness to the original game feel, etc.) and there could be a user who would want to install more than one. These would (possibly) use the same (independent, optional) data files. Just as with uqm there are multiple data files and each is optional, but this is the more complex case: multiple optional data files that work with multiple (somewhat) optional apps.
Links
Talk thread | Fragmented, obsolete wiki page on the issue
