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

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

New Mac owner here, but long time Linux user. Can anyone describe to me the differences between installing a piece of software, such as Subversion, from a .dmg image as opposed to compiling and installing from source on the command line? Does the software end up in the same location? What other differences exist, such as uninstallation procedures? What would you consider the pros/cons of one approach over the other?

Asked by: Guest | Views: 264

Total answers/comments: 2

Comments display order:

Guest [Entry]

"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."

Guest [Entry]

"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/"