Mac OS X - installing software via DMG vs. *nix command line style

A .dmg is just a virtual disk ("disk image"), and on its own has nothing to do with installation.

When the disk image contains just an application (usually there will be some explanatory text asking you to drag it to your Applications folder), then all the code and support files are contained within that one file. The application is responsible for doing any setup on first launch and responsible for providing an uninstall mechanism if anything is installed later on. Many developers are using the Sparkle framework to find and install updates.

If the disk image contains a package (.pkg or .mpkg), that's an installer. Running it could install files anywhere on your system and run pre- and post-install scripts, and there's no built-in uninstall or upgrade mechanism (the system does keep a log of installed packages, though, so if you later run an installer package for a newer version of the software, it may behave differently than if it had been a first install). In this case, too, the developer is responsible for uninstall and responsivle for updates. Responsible developers will install to standard directories (/Applications, /Library and ~/Library, /usr, etc.)

For command line software that you'd typically install from source, I'd recommend a package manager like MacPorts (my preference) or Fink over using an installer package. Both of those package managers set up a self-contained directory (/opt and /sw, respectively) with all the support files and executable code for software they install (and most packages respect it), and add themselves to your $PATH. A huge advantage of using a package manager is that it'll keep track of installed software and give you the ability to upgrade or uninstall it.

Installing from a .dmg typically is just a drag and drop to /Applications. Uninstalling is one sore point in the Mac experience, in my opinion. You can delete the file from Applications, but only that stuff which is encapsulated in the .app wrapper will be gone. Any additional configuration files don't disappear.

Another installation path you should consider is MacPorts and/or Fink. These are somewhat similar to apt-get or yum in the linux world. They provide a command line utility for grabbing, compiling and installing common software. It's usually as simple as:

$ sudo port install svn

(macport example)

This is somewhat complicated, because inside the DMG there may be a simple drag-n-drop solution, or a .PKG, which may install things in any location. .pkg's normally leave reciepts (usually in /Library/Receipts), though OS X offers no easy way to manage those recipts.

Pacifist is a useful app that examines .pkg files (which many command-line apps use for custom install locations) before install so you can understand exactly where things may be installed. You can then determine if your self-compiled version would be installed in the same location or not, and if they will conflict with system versions:

http://www.charlessoft.com/

Specifically, you will need to make sure if they install to different locations, that your path reflects the desired version you wqish to use. I suspect subversion shouldn't be problematic with multiple versions installed... For Ruby, I use a ruby19 name for the ruby executable to stop any path problems with incompatible code.

There is a less-powerful, but free quicklook plugin for .pkg files which does the basic job of show where things will be installed:

http://www.mothersruin.com/software/SuspiciousPackage/