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?
MacOS Installation – DMG vs Command Line Software Installation
dmg-imageinstallationmacos
Related Solutions
DMG stands for Apple Disk Image. These are treated like a Volume of their own, but one that's contained in that file. Volumes on a Mac are basically any physical or virtual disk that can be mounted permanently or temporarily. The hard drive icon you see on your desktop (probably Macintosh HD unless you renamed it) is a volume. You can clone one volume to another easily, whether it be physical or virtual. This is one of the features that makes a Mac so powerful.
These volumes are "mounted" or "unmounted" on the Mac OS. This is similar to Windows in that when a removable drive is plugged it, it's automatically assigned a drive letter (E:)... in other words, it's mounted. When you "safely remove" it, you're unmounting it. You must always unmount a drive on the Mac OS before removing it, whether it be physical or virtual.
A DMG is similar to any other compressed file, like ZIP in Windows, but more powerful on the Mac OS. The DMG is a self contained volume formated HFS+ that retains file system attributes that are important. These are called resource forks and are usually invisible to Mac users. If you've ever copied a file from your Mac HD onto a FAT32 thumb drive, then plugged that drive into a Windows box and seen those pesky "._name" files, those are resource forks. They're important to a Mac as they contain metadata pertaining to the file itself.
When you download a disk image containing an Application, the app should be copied to your Applications folder before running it. This is because most disk images are read-only, and running it from inside the disk image can produce undesirable results.
Some Applications come in a package which are handled by the Macintosh Installer. These usually need to write system setting files that require administrative access and will prompt you for your password. Make sure you know where a package came from before giving it your administrative password.
The application, when launched, will create a few files that it needs in your Library folder in your Users directory (your username... looks like a Home icon in Finder). Settings you change while using the application are stored into these files, so if you "uninstall" the application by moving it into the trash, then re-install it later, those settings are retained. This can be a good or bad thing, depending on what you want. If you want to completely remove an application along with all of it's settings pertaining to you and/or the system, first see if the Application came with an uninstaller. This might be in the application folder itself or in Utilities (Adobe is notorious for having it's own uninstallers). Usually, if an application was installed via Macintosh Installer, it will have it's own uninstaller or you can visit the company website for instructions on how to remove it. If it was a standalone application and you want to completely remove everything related to it, you can use a great free program such as AppCleaner to do this.
Hope that helps some. Enjoy Mac!
Most .dmg files are read-only. A common workaround is to copy the contents of a mounted .dmg to a folder on your hard drive, and making your edits on that copy.
If for some reason that workaround won't work for you (not enough free disk space perhaps?), you can mount a read-only disk image with a "shadow file" to make it act writable. All writes are actually written to the shadow file instead of the original read-only .dmg, which is left untouched.
hdiutil attach -shadow filename.shadow filename.dmg
Best Answer
A
.dmgis 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 (
.pkgor.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,/Libraryand~/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 (
/optand/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.