<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Brian J. Tarricone wrote:<br> <blockquote cite="mid:20081112090655.1beb80f3@kepler" type="cite"> <blockquote type="cite"> <pre wrap="">Generally, $HOME/bin/`arch` for binaries, or $HOME/lib/`arch`... It can get tricky for things like GIMP plugins. </pre> </blockquote> <pre wrap=""> Yes, but who actually *does* this? As much as it would be nice if everyone did, it's rare for an app to consider multi-arch on the same filesystem. </pre> </blockquote> I think you can look at multi-arch in different ways:<br> 1) You keep stuff for multiple arches in your $HOME/<whatever> directory, because that's just where you keep your stuff, as suggested above<br> 2) You keep the "source" of the files that _end up_ in $HOME/<whatever> in a separate 'source' directory independent of the 'installation' directory.  You can then write scripts/tools/package manager or whatever to "install" your stuff (from source code, build directories, custom packages,... Could be on your own system or somewhere else) into the $HOME/<whatever> directory.  That's how I see it.  I don't see $HOME/bin or something as important per se, I only see it as a destination of something else.  And that something else needs to be controlled.<br> </body> </html>