One way of going about this is to make a group out of these packages with a special policy, just as we have them for command line apps. Description mentions are IMHO not the best solution as it's too easy to skip/miss them and then you're left wondering why this stuff doesn't work. My first thought about doing it in the least invasive, but firm and informative manner is to use a bootstrapper/launcher - the actual app would not be started directly, but instead would depend on a (provisional name) external-game-data package (not in a user section) and would be required to start that from the .desktop file. It would also drop two files in /etc/externalgamedata.d/, a packagename.files and a packagename.info, the first containing the paths required, and the second that displays info where these can be obtained from. Then, when the end user launches the app, the launcher checks if the files are present, if yes, cool, launch game, if not, show info dialog which clearly states what goes where. Personally, I would maybe also require game data to be in MyDocs (so users could just drop it via USB), though this might encounter tech problems (due to VFAT limits). Thoughts ? I will gladly make such a launcher in bash if we have a consensus of doing things this way.

I think if app doesn't work at all without external packages there should be at least link to installation instructions to those packages, and app shouldn't get accepted without them. There should also be notification about it in package description.

The policy should be as simple as this:

• Each of the applications requiring some external files clearly must indicate this in its description
• The apps' descriptions should contain how to obtain the external files
• After installing such an app, a message must pop up that informs the user about it
• The app must provide meaningful error messages if the external files are not there

These should be some little extra work from the developers, but very helpful for end users.

Well, this is pretty much what I described above The external package/launcher is IMHO a good solution for this because it does not require each and every maintainer to come up with such a solution on his/her own, i.e. it requires no actual code changes, just config file differences (if you depend on the given package and state your files, all of what you list would happen automatically). I find 'how to use this app' in the description fields too obscure, maybe even non-intuitive. I know we're using it for that now, but only because we don't have a real alternative.