The Luggage is also beneficial for anyone wanting to manage how installers change over time, because it can be used in conjunction with version control. Version control lets you control the revisions to files.
Just to be clear, the Luggage neither provides version control itself, nor requires it. If you are unfamiliar with version control systems like Mercurial, Git, or Subversion, you can start using the Luggage without them. However, to get the full benefits of the Luggage, it pays to understand and use version control because it lets you see the changes you make to your installer files over time and revert back to previous versions if necessary.
In short, version control gives you really advanced “undo-redo” capabilities for your projects.
Many of the source files for your installer, particularly if you’re a system administrator, will be text files of some sort. Text files, like property lists and typical UNIX configuration files, are ideal for placing under version control. The various scripts — preinstall, postinstall, InstallationCheck, and VolumeCheck, for example — that you may include in your installer are also great candidates for revision control. You can include them right in your version control repository along with the makefile necessary for the Luggage.
Placing these files into version control repository helps you manage the changes to they evolve. The differences between versions of text files can be easily tracked by these systems. By including files in such a repository, you can also take advantage of your version control system to begin tracking changes to your installer project’s own makefile (used by the Luggage).
When you make changes to one of the source data files or the makefile, just make sure you check them in to your revision control system. Typically, you’ll want to do so after you make an important change — one that you’ve tested to ensure it works correctly.
Other resources might include picture files and perhaps even application binaries or bundles. You can optionally include these files, and that’s up to you, because binary files are not ideal version control candidates. You can still track changes to them, but the differences may not be illuminating.
All the Luggage needs for bundling up basic application installations — a common use case — is an archive of the bundle. (The archive must be in tar format, and must be compressed with either gzip or bzip2.) As long as you can obtain the relevant files with one or more UNIX shell commands during the Luggage’s build process, you can probably make use of them with the Luggage.
An application’s archive file could be in stored in the repository or obtained from elsewhere. You will have to decide whether it is important to you to track changes to that a blob of data or not.