I've been giving some thought to that on the OSX side, mostly with regards to the packaging system. I'm not sure what's the most convenient way to make installable packages on the MacOSX side of things. Apple's .pkg is attractive, but the current package format doesn't seem to be very manipulable by the command-line.
why even bother with a packaging system for the binary? how about this for an install on OSX:
step one: download binary step two: un-tar/zip/stuff downloaded file step three: open pd folder and double click on CLICK_ME_TO_RUN_PD smiley face icon
for step three to happen, write a pdstart.command that has ./pd -options and put it in the pd/bin dir. make an alias to it with that big smiley face icon at the root of the pd folder.
i don't think you can assume that the typical Mac user uses the command line at all, so OSX apps should take that into account. the above approach seems to be in line with most free/shareware applications distributed for OSX, which will make Mac users feel right at home.
one thing to work out is explaining how the runtime options are used. this could be a point of confusion for people when they first try to setup their midi/audio and add various libs to pd.
Also--where do they go? The /usr/local tree (where I personally prefer to put pd) is typically hidden from the user. It would be nice to be able to put files in a place like /Library/Pd, where an ordinary user has the capability to scre^H^H^H^Hmanipulate their installation in the finder.
i think you have answered your own question. the OSX version of pd should go where the user wants it to go. if you install to /usr/local that would make pd vanish to the majority of mac users!
We could emulate your debian approach--how does that lay out files for externals (and their associated source, help, and other files)?
why emulate debian at all? it's not debian it's OSX. if anything it should more closely resemble the win32 version.
cgc