Do not be wary of noobdom, I needed this perspective to see how lacking the docs I made are. InstaUp2Date will not redownload the patches, or ever again, if it finds the dmg/pkg in a ‘guessed’ location(e.g. /Caches/instaUp2DateCache). This means when it runs, if it sees a dmg at either:
a. the filesystem path as specified in a line in the catalog file if you manually added one(or optionally generated it with the checksum.py tool to spit out the proper syntax for you)
or(commonly for a URL path)b. in the /Caches/instaUp2DateCache folder with a matching filename/checksum
, it knows to use that local one.

A drawback is when you’re rapidly developing packages to include you do need to generate a new checksum each time, but the rest of the info would stay the same.

Instadmg.bash exhibits slightly different behavior by default(as you noticed, due in part to the lack of the flags up2date uses in its handoff), but the premise is the same: you follow convention and patch the OS before any additional apps and then the settings would get laid on top at the end. The vanilla catalog files means you don’t have to care what the current patches are for any models in your fleet(I’m even covering the new, forked ones) – trust the crowd-sourced versions I happen to curate. And using up2date means you don’t have to manually download those patches, since the python process fetches them for you. On top of that, you don’t have to move folders around when you want to build a different combination of software, either.

Another enhancement is to take advantage of the branch-able nature of the catalog files. You can use the ‘include-file [i]path/to/my/specific/catalog/file[/i]’ syntax to have one base catalog file incorporate others, and then you only need to update the things specific to your builds in one place, but the referenced, continually-updated vanilla catalog files(and/or, additionally, the forked models catalog file) that are included for you take care of the rest and stay current. There are a number of variables you can configure in a base catalog file as well, which means you don’t need to pass as many flags to the command-line process at runtime, and it becomes a more scriptable(or less manual thought) process.

Please let me know what else could be clearer or better described. Thanks, Allister